[Geany-devel] Performance issues?

Lex Trotman elextr at xxxxx
Mon Mar 28 03:10:16 UTC 2011


On 28 March 2011 12:35, Thomas Martitz
<thomas.martitz at student.htw-berlin.de> wrote:
> On 27.03.2011 05:15, Lex Trotman wrote:
>>
>> The question is can problems be introduced by not reparsing things, eg
>> if we are editing a .h file, can that affect the symbols of the .c
>> files that include it ... probably possible AFAICT.
>>
>> Is there some easy way of triggering re-parsing of dependencies when
>> the sidebar is about to swap to a different file?  That way real-time
>> update only needs to do the one file being edited, but no artifacts
>> are introduced due to inconsistencies between when tags were parsed.
>>
>> Cheers
>> Lex
>
> Is the tag parsing even dependency aware? I thought it simply collects tags
> from all open files (and pre-loaded tag files).
>
> Best regards.

Well its not really dependency aware, in the non-real-time version it
does it by reparseing *all* files in the workspace when any one of
them is saved, so there can be no inconsistency.
It is the fact that its doing all of them on real-time update that is
the performance problem, so we want to real-time parse only the file
we are editing.

Not being certain what inconsistencies there might be, I'd suggest
trying it, only parse the one file real-time and all the others at
save time, ie apply Yura's patch (below) and see.

--- a/src/document.c
+++ b/src/document.c
@@ -2263,7 +2263,7 @@ static gboolean
update_tags_from_buffer(GeanyDocument *doc)
               /* we copy the whole text into memory instead using a
direct char pointer from
                * Scintilla because tm_source_file_buffer_update()
does modify the string slightly */
               sci_get_text(doc->editor->sci, len, text);
-               result = tm_source_file_buffer_update(doc->tm_file,
(guchar*) text, len, TRUE);
+               result = tm_source_file_buffer_update(doc->tm_file,
(guchar*) text, len, FALSE);
               g_free(text);
 #endif
       return result;



Cheers
Lex



More information about the Devel mailing list