[Geany-devel] Performance issues?

[Colomban Wendling]

Hi,

Le 28/03/2011 05:10, Lex Trotman a écrit :
> 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.

AFAICT it is possible but unlikely since the only thing that would have
this kind of "side effects" is the C/C++ (and probably D) preprocessor
(e.g. if a constant changing conditional code changes). Not 100% sure
though.

>>> 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.

I don't know (without further search), but I'm not sure it'd resolve the
"issue", since while editing file 1 you wouldn't get the changes from
file 2.
But again, not sure it's a real issue.

> 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.

True. Moreover -- as far as I can understand the TagManager code (so,
only more or less :D) -- the parent updates will not be done in-memory,
so it's definitely a problem we should solve.

> 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.

Agreed. However the patch would *always* disable updating parent, what
we probably don't want (though, not really sure what it'd change). So I
have modified it and committed it to SVN (r5642).

Hope this fixes the issue, feedback welcome.
And guys, thanks a lot for tracking this down!

Cheers,
Colomban