Thanks for the detailed analysis of what was going on.
I'll look into the metatype recursion example later this fall. I've
CC'd Klaus in case he missed this information about ECB.
Eric
On 11/01/2010 06:04 AM, Marc Herbert wrote:
>>> ... started spewing "Possible metatype recursion for<some
>>> Qt type>" messages. [...] This took several seconds and Emacs
>>> was unresponsive during that time. If I moved away from that
>>> position and then came back, it would start all over again! (It
>>> may have started again even without me moving away and coming back,
>>> can't remember.)
>>
>> If there are self-referential symbols somewhere, that would do that.
>> For example:
>>
>> typedef foo bar;
>> typedef bar foo;
>>
>> foo mysym;
>
>> Hopefully the above typedef explanation helps. If not, let me know.
>
> [Entire parent message quoted at the bottom]
>
>
> In my case these "Possible metatype recursion" errors are not caused
> by typedefs but forward struct declarations. I could easily get rid of
> these error messages with a hack like this:
>
> #ifndef EMACS_ECB
> struct foo;
> struct bar;
> #endif
>
> (ede-cpp-root-project
> :spp-table '(
> ("EMACS_ECB" . "")
>
>
> HOWEVER, these errors were just the tip of the iceberg. Getting rid of
> them did NOT get rid of the constantly recurring 20 seconds
> unresponsiveness on some big C files.
>
> ------------
>
> My freeze problem basically came down to this:
>
> 1. (senator-force-refresh) needs 7-8 seconds on some specific 1.4M C
> file (whereas a 500K file in the same probject needs less than 1
> seconds)
>
> 2. ECB makes things many times slower on any file. Of course for most
> files zero multiplied by many is still zero, which hides the problem.
>
> ECB makes things much slower in two ways:
>
> A. When ECB's "analyse" window is displayed, clicking anywhere seems
> to force a full reparse. In other words, every click costs more than
> 20 seconds.
>
> B. As soon as ECB's "methods" window is displayed, the duration of
> (senator-force-refresh) jumps to more than 20 seconds. The progress
> bar takes just as long, but "something" ECB seems to hook at the end
> of the semantic reparse and take more than 10 seconds. This notably
> happens every time I save the file.
>
>
> I solved problem 1. thanks to:
> '(semantic-idle-scheduler-max-buffer-size 1000000)
> ... and refreshing manually this specific file.
>
> But since ECB keeps calling semantic anyway the war was far from
> over. To win I also needed this:
>
> ; workaround problem A:
> '(ecb-analyse-buffer-sync nil)
> ; workaround problem B:
> '(ecb-auto-update-methods-after-save nil)
>
> And now I have to run (ecb-window-sync) manually from time to
> time but that is OK.
>
> What is totally amazing is that the time to manually run
> (ecb-window-sync) is barely more than 10 seconds: about twice faster
> than the freeze in "auto" mode! It looks like ECB's "auto" mode(s)
> badly fail to cache information somehow.
>
> s-tracing shows almost no system calls during the freeze except a dozen
> of brk().
>
> I am running emacs 23.2, CEDET 1.0 and ECB 2.40. A good, stable
> combination except for this performance issue.
>
> Hope this helps.
>
>
> Regards,
>
> Marc
>
>
> Le 03/10/2009 14:21, Eric M. Ludlam a ecrit:
>> On Sat, 2009-10-03 at 01:17 +0300, Hannu Koivisto wrote:
>>> Greetings,
>>>
>>> I'm working on a Qt project which I actually haven't configured as
>>> an ede-cpp-root-project at all (yet, I'm planning on writing a tool
>>> that automatically generates ede-cpp-root-projects from Qt project
>>> files on the fly) but I nevertheless have CEDET enabled, system
>>> include paths contain paths to Qt headers and they are found. I
>>> have no other Qt specific settings despite that I've seen some
>>> discussions that something extra might be needed for better
>>> operation.
>>
>> While creating ede-cpp-root projects would be an Emacsy thing to do, you
>> can create new kinds of EDE projects instead. Project setup provides a
>> hook for project detection you can use. For example, if a project using
>> Qt always has some file called QT at the root, you can use that to
>> detect the project, and automatically create a custom EDE project style.
>> That EDE project can then provide the include paths, custom macros, or
>> whatever else is needed.
>>
>> For C++ and libraries such as Qt, it might be needed to have some sort
>> of library recognition that could be shared between project types, such
>> that you could say an ede-cpp-root-project, or an automake project could
>> take advantage of an encoding of Qt configuration options. You could
>> then have a program that needs Qt and linux kernel sources together. I
>> have no special items for such a thing at this time though, so it would
>> be worth designing.
>>
>>> I faced at least one "emit SomeSignal();" line which caused bad
>>> things to happen. When I had the cursor inside the parens and I
>>> didn't do anything for awhile, CEDET, apparently during idle
>>> processing, started spewing "Possible metatype recursion for<some
>>> Qt type>" messages. Types were quite basic stuff like QChar,
>>> QRect, etc. I got over 60 lines to *Messages* and some lines were
>>> repeated for example 25 times. This took several seconds and Emacs
>>> was unresponsive during that time. If I moved away from that
>>> position and then came back, it would start all over again! (It
>>> may have started again even without me moving away and coming back,
>>> can't remember.)
>>
>> If there are self-referential symbols somewhere, that would do that.
>> For example:
>>
>> typedef foo bar;
>> typedef bar foo;
>>
>> foo mysym;
>>
>> When the Emacs idle stuff starts complaining like that, the thing to do
>> is use:
>>
>> M-x semantic-debug-idle-function
>>
>> though the above message is not an error. For completion problems, you
>> can use:
>>
>> M-x semantic-analyze-debug-assist
>>
>> which might provide some details on the metatype it is complaining
>> about.
>>
>>> I can't disclose that source code and I haven't yet been able to
>>> create a small test case. My questions:
>>>
>>> 1) is that something that might be caused by the lack of
>>> Qt-specific extra settings, whatever they might be? Or is it that
>>> possible extra settings only help CEDET perform better, not avoid
>>> this kind of bugs? I hope the former, because otherwise you would
>>> need to disable CEDET just to, say, browse some Qt-project that you
>>> don't intend to otherwise work on.
>>
>> At this point, I don't know. It is likely code specific, but there may
>> be some macro involved that isn't parsing right either.
>>
>>> 2) if 1) is not a likely cause, could someone explain what that
>>> metatype recursion means and what are possible causes for it, so
>>> that I might be able to use that information to distill the
>>> problematic part of code into a small test case?
>>
>> Hopefully the above typedef explanation helps. If not, let me know.
>>
>> Eric
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry® Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9-12, 2009. Register now!
>> http://p.sf.net/sfu/devconf
>
>
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps& games for the Nokia N8 for consumers in U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Cedet-devel mailing list
> Cedet-devel@...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>
|