[Geany-Devel] Geany performance
Pavel Roschin
rpg89 at xxxxx
Sun Sep 29 08:40:10 UTC 2013
> Agreed. But here's the thing: every single file that is loaded needs to be:
>
> 1) Loaded from disk (slow)
> - Malloc a C string for whole document
> 2) Copied into scintilla buffer
> - Freed whole document string
> 3) Completely lexed by Scintilla lexer (blocking for huge docs)
> 4) Grabbing the raw char* of the buffer from Scintilla.
> 5) ** Does it take a whole other copy here? **
> 6) Passing through CTags and TM (blocking for huge docs).
> 7) Updating the user CTags into Scintilla keywords. (SCI_SETKEYWORDS
> with Ctags results)
> 8) Updating the Symbols tree view with new parsed tags.
> 9) Focusing the GTK+ notebook page
> 10) Setting caret pos to 0 which should be the natural position of the
> caret but who knows what magic Scintilla does when moving caret.
>
> At present, most of these steps can't be delayed, they all kind of
> depend on the others due to Geany assuming a single thread on a single
> core and sharing a bunch of the loaded data globally between modules.
I'm talking about bulk file loading. Loading single file is fast enough, it
slow when you "Focusing the GTK+ notebook page" for EACH file even if it will
not be ever shown (because there are more files in queue).
> If you have a single project with 10M files, surely you are doing
> something wrong :)
Google in Chromium project definitely does something wrong?:)
> Indeed we would encourage any contributions here, but just remember it's
> existing software with certain hardcoded assumptions that have to be
> lived with. It's easy to bikeshed about how stuff should be, it's a
> whole different story to actually update the gnarly code to make it a
> reality and not break everyone's IDE in the process :)
Of course I cannot predict, that simple instruction:
if(pos == sci_get_current_position(sci)) return;
will break something. But if it will, there are _serious_ architecture issues.
But maybe experimenting on beta-testing stage isn't crazy idea?
--
Best regards,
Pavel Roschin aka RPG
More information about the Devel
mailing list