>>> Stefan =?iso-8859-1?Q?Reich=F6r?= <stefan@...> seems to think that:
>> I've made two changes to CEDET/semantic this evening.
>> 1) semantic-load will no longer turn on minimum features by default.
>> This slows things down for installs where users just want to use
>> CEDET to get at EIEIO or Speedbar only. If you depended on this
>> default, you will need to update your .emacs file.
>> loading cedet.el will now take under a second, even on slower
>> 2) I think I've fixed a long standing python parser speed bug.
>> This relates to implicit joining. I'm now using the parser to
>> identify when we lex into a paren block, and use that state to answer
>> the question, instead of the old text scanning mechanism.
>> If you know python, please investigate the test.py for the new
>> examples. I know nothing about python and guessed that this was the
>> right thing to do. New items are start at line 51.
>I compared the old python parser with the new one. The results are
>The file size is 130kB.
>The old parser needed 53 seconds
>The new parser finishes in 2 seconds
Great news! Thanks for letting me know.
>Eric, thanks for finding and fixing this long standing performance
The real question is... does it produce a correct answer? I found it
produced a different answer for:
type code, which is, I think, what the offending routine was
attempting to parse in the first place. I don't even know if that is
correct syntax or not.
For code like this:
a_tuple = (1, 2, 3,
4, 5, 6)
the lexer never went inside those parens.
To see if it produces the correct answer, I like to place the cursor
in the text of a tag I'd like to investigate, and type:
M-x semantic-test-all-format-tag-functions RET
which usually does a good job of showing what's up.
Eric Ludlam: zappo@..., eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org