[Geany-devel] Performance issues? [PATCH]

[Colomban Wendling]

Le 28/03/2011 23:46, Lex Trotman a écrit :
> On 29 March 2011 08:29, Yura Siamashka <yurand2 at gmail.com> wrote:
>> On Mon, 28 Mar 2011 23:00:54 +0200
>> Colomban Wendling <lists.ban at herbesfolles.org> wrote:
>>
>>>> Anyway here is patch that make Geany don't parse tags when user is actively typing.
>>>
>>> I'm not sure about this patch, because it is then really easy to make
>>> the tag list never update automatically.
>>> E.g. if update timeout is set to 1s, just type something every 999ms and
>>> then update will never happen, even if there is actually 1s free to do it.
>>
>> Please show me that energeezer that type something every second and
> even have time to inspect tags while doing it. :) It is quite
> unrealistic to me. On other hand if someone is just typing parse delay
> can be annoying if his file is HUGE.

Probably true, I'll test this a bit and see what I feel about it in
real-world usage.

>>> But maybe I'm worrying too much and this only need the timeout to be
>>> configured otherwise, I may try to tune this if you really think it's
>>> important.
>>>
>>> I also plan to try to move the TagManager parsing in a separate thread
>>> at some point, maybe it'll help (though maybe it's the UI update that
>>> takes most of the time...).
>>
>> No, I suspected this first and disabled UI update during research (delay
> seemed the same), but maybe it is worth to make smart update. Parser
> report that some tags were actually changed and you call UI update only
> then (if it is not done already)

May be a possible trick. However we currently can't tell whether the
symbol list changed, so it'd have to be an extra step.

> Seems to me that none of this answers the original question of why is
> the lag much greater when both Geanyprj and real-time update are in
> use, compared to the lag when only one of them is in use?

Let's hope it's only the parent update that poses problems (and should
then be fixed, hopefully without too much side effects), what seem a
good explanation to me (and to Yura's tests IIRC).

> If we could answer that then adding delays etc would be immaterial :-)

Well, parsing of very large files *is* slow (e.g. the update of a test
file of ~64k lines of standard C code (9000+ tags) takes 1,6s --
including UI update though, which might be a significant part), so
improving it probably can't be bad :)

Cheers,
Colomban