Le 28/03/2011 23:46, Lex Trotman a écrit :
On 29 March 2011 08:29, Yura Siamashka yurand2@gmail.com wrote:
On Mon, 28 Mar 2011 23:00:54 +0200 Colomban Wendling lists.ban@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