Re: [CEDET-devel] return values with locally scoped types
Brought to you by:
zappo
From: David E. <de...@ra...> - 2011-06-03 16:53:30
|
Eric M. Ludlam writes: > Hi David, > > Interesting new issues. To figure out performance, just put the cursor > on some example, and do: > > M-x semantic-elp-analyze RET Problem is that one completion takes ~0.1s, which is not long enough to give a significant measure. Instead, I used the whole semantic-ia-utest suite; `semantic-analyze-find-tag-sequence' is called 115 times there. Turns out, my addition of one semantic-calculate-scope did make the unit test about 7% slower. While this isn't terrible and it mainly affects completion, I still didn't like it, especially because most of the time is done in the search for local variables, which I figure is only necessary for very special cases (which I will surely stumble upon, but not today). So instead of a full scope calculation, I only look for the parents and their scope, and include it for the next iteration: *** semantic/semantic-analyze.el 2010-04-18 21:45:44 +0000 --- semantic/semantic-analyze.el 2011-06-03 15:06:33 +0000 *************** *** 341,346 **** --- 341,367 ---- (when (and fname (semantic-tag-p tmp) (not (semantic-tag-in-buffer-p tmp))) (semantic--tag-put-property tmp :filename fname)) + + (when (and (cdr s) + tmp + (semantic-tag-p tmp)) + (save-excursion + (semantic-go-to-tag tmp) + (let ((parents (semantic-analyze-scope-nested-tags (point) nil)) + (newscope (semantic-scope-cache "miniscope")) + parentscope rawscope) + (when parents + (oset newscope parents parents) + (setq parentscope + (semantic-analyze-scoped-tags nil newscope))) + (setq rawscope + (semantic-tag-type-members tmptype)) + (when (or parentscope rawscope) + (oset scope fullscope + (append rawscope + parentscope + (oref scope fullscope))))))) + (setq tag (cons tmp tag)) (setq tagtype (cons tmptype tagtype)) ) This also makes the code slower, but just a tiny bit. Here's one sample: Old code: semantic-ia-utest 1 8.111613 8.111613 semantic-parse-region 793 3.4006790000 0.0042883720 semantic-parse-region-default 793 3.3928430000 0.0042784905 semantic-calculate-scope 135 3.361651 0.0249011185 semantic-parse-region-c-mode 679 3.1108660000 0.0045815405 semantic-analyze-current-context 88 3.0281379999 0.0344106590 semantic-ia-utest-buffer 12 3.0275339999 0.2522945 semantic-analyze-current-context-default 88 3.0237289999 0.0343605568 semantic-repeat-parse-whole-stream 793 2.6946140000 0.0033980000 semantic-parse-stream 5511 2.4156130000 0.0004383257 semantic-parse-stream-default 5370 2.3667209999 0.0004407301 semantic-bovinate-stream 5370 2.3538729999 0.0004383376 semantic-fetch-tags 1436 2.3070329999 0.0016065689 New code: semantic-ia-utest 1 8.162042 8.162042 semantic-parse-region 793 3.4838440000 0.0043932459 semantic-parse-region-default 793 3.3902579999 0.0042752307 semantic-calculate-scope 135 3.3376609999 0.0247234148 semantic-parse-region-c-mode 679 3.1951430000 0.0047056597 semantic-ia-utest-buffer 12 3.071324 0.2559436666 semantic-analyze-current-context 88 3.0705029999 0.0348920795 semantic-analyze-current-context-default 88 3.0660609999 0.0348416022 semantic-repeat-parse-whole-stream 793 2.6827439999 0.0033830315 semantic-parse-stream 5511 2.5633560000 0.0004651344 semantic-parse-stream-default 5370 2.4686579999 0.0004597128 semantic-bovinate-stream 5370 2.4563239999 0.0004574160 semantic-fetch-tags 1452 2.3299349999 0.0016046384 You see the difference consists mainly of 16 additional calls to semantic-fetch-tags for 115 calls to semantic-analyze-find-tag-sequence. > I would guess your code won't do much if the local context doesn't have > the case where this extra work is needed?? That would be the best > solution as a little performance issue is fine for more complex problems. Well, you usually define your structures and classes outside the local scope, so this is actually a very common thing. And unfortunately, we cannot know if it is really necessary until we've done it... I could implement this as a fallback if `semantic-analyze-tag-type' doesn't return anything, but I think this somewhat ugly, and in practical situations this may even be slower, since failing completions are pretty common and we'll then do double work. -David |