Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
lexer file loading ...
thomas:
Michael's approach is good, as it addresses the actual problem, which is not TinyXML being slow, but loading many lexers that are unneeded.
Face it, we have more lexers that are complete nonsense than lexers that are actually used by anyone. Out of the 22 lexers loaded at startup, the "average" user will use 2, maybe 3.
Peeking into the sources for 10 seconds, I found an additional issue with lexer loading that has not been noticed so far: it is not Unicode-safe. I wonder nobody has complained about lexers not working at all in Czech and Russian installations yet... :shock:
Being fed up with my other stuff at the moment, I'll have a look at what can be done about lexer loading after dinner :)
takeshimiya:
I've spent various days trying to understand this issue (why the C::B loading was slow).
Limiting the loaded lexers could be a temporal quick fix until a better solution is implemented.
Here are some of my tests on my pc:
C::B loading on first time: 15 seconds. C::B loading on subsequent times: 5 seconds.
The lexers parsing take a constant time everytime, and the difference between the first and subsequent time is mostly attributed to the DLLs loading.
TinyXML parsing is slow, with a rough measure of 200ms each lexer.
A bottom note:
At my univ. which I can only load C::B from the LAN, C::B takes 50 seconds to load. SciTE takes 1 second.
SciTE loads way more lexers than C::B. The SciTE lexers also have more features.
We can do better. :)
There are multiple ways to improve things. It needs time.
Michael:
--- Quote from: Michael on April 04, 2006, 03:25:00 pm ---May be it could be useful to just load only the "most important" of them at the beginning (C::B default) and then let the user decides if she/he needs additional ones or not (as with the plugins). For example, I do not use f77 lexer, so why I have to load it?
--- End quote ---
Hello,
I have had some time to thinking about an alternative :). May be lexers could be handle as file associations are. Depending on which kind of file a user open, C::B loads the relative lexer automatically. So, it would not be necessary to load at the beginning 2-3 basic lexers (to decide which of them could not be so easier...).
By default C::B has pre-defined associations (stored into the C::B config file?). Each type of file has its lexer. The user has the possibility to modify this list by either adding a new lexer and its relative file type association and/or to modify an existing one. User specific lexers could be stored separately into the C::B config file (or an alternative lexer config file).
May be the lexers used by project or workspace could be stored into .cbp or .workspace files, so that when loading a project or workspace, C::B loads directly the necessary lexers without having to parser the file types to get the corresponding lexers.
This method has the advantage to make the handling of lexers automatic with "no" or very limited additional overhaed for the user. The disadvantage is a bit more overhead for C::B as it would be necessary to e.g., check that a lexer is not loaded several times.
If you have questions and or comments, please do not hesitate :).
Best wishes,
Michael
mandrav:
Revision 2306 has fixed the delay when opening "Settings->Editor". That's a start ;).
Michael:
--- Quote from: mandrav on April 05, 2006, 11:28:14 am ---Revision 2306 has fixed the delay when opening "Settings->Editor". That's a start ;).
--- End quote ---
Great :D.
I have remarked that this morning there were several commits. Each time I have built a C::B revision, I have discovered a new one :D.
Best wishes,
Michael
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version