Re: [pygccxml-development] Another way to speed up the generation process...
Brought to you by:
mbaas,
roman_yakovenko
From: Matthias B. <ba...@ir...> - 2006-10-21 12:39:42
|
Roman Yakovenko wrote: > I appreciate your efforts to speed up cod generation process. This > specific patch > will not find its way to Py++ :-(. It is too dangerous: It's not meant to be a patch anyway. I just posted the function so that anyone who thinks it is useful can incorporate it into their generation scripts (in my case, I made it available via pypp_api (but it still has to be called by the user explicitly, it's not called automatically by pypp_api)). > While remove_declarations works as you expect, the functionality is broken. > For example: base and derived classes. if you remove base class from the > declaration tree, base class still will be accessible from the derived > "bases" > property. Or if some function takes as argument instance of some class > and you remove the class from the declaration tree, the type of argument > will continue to keep reference to the class. Looks like those kind of problems do not appear in my case. I'm not aware that the Maya SDK uses any class from outside the SDK. The generated code after pruning is the same as before, so I guess it's ok for me to take advantage of the pruning. :) So the feature I'd like to see eventually is just that I can tell Py++ in advance that I will only be querying (and exposing) declarations from a particular set of header files and that all other declarations are not interesting to me and can be safely ignored for any query operation and they also don't have to be stored in the cache (unfortunately, I don't have the latter yet). Then it's still up to Py++ if it has to keep some of the declarations but at least I could expect that they won't slow down a query operation anymore and that the cache is kept at a reasonable size. As mentioned in my previous post, under OSX I'm only interested in about 1.5% of the declarations in the top-level namespace. Everything else is junk that just slows down the generation process. Reading the cache still takes about 1:10 minutes (about 1/3 of the entire execution time) while parsing the code without cache takes about 1:45 minutes (on Linux it is ~7s vs ~1:30min). > Can you post your profiler results? May be we can find something that > could\should be fixed. Sorry, I didn't use a profiler. I was just using the regular output of the driver script. - Matthias - |