Re: [pygccxml-development] Another way to speed up the generation process...

[Roman Y. <rom...@gm...>]

On 10/20/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> I just thought I'd share a little code snippet that can be useful to
> speed up the bindings generation process. The below function simply
> removes all declaration nodes that do not originate from the specified
> directories (i.e. it removes all the system chunk that is not going to
> be wrapped anyway). So you should call that function right after the
> parsing step.
> I noticed that these extra nodes can eat up a lot of time as I was
> porting my script over to OSX where a lot more system headers are read.
> On Linux the running time was reduced from about 4:40 minutes to around
> 3:20 minutes and on OSX it went down from 7:20 minutes to 4:10 minutes.
>
> On OSX the top-level namespace contained more than 20000 nodes whereas
> on Linux it was only about 4700 nodes. What I still have to investigate
> is how the cache can be modified so that it stores the data *after*
> pruning. It's a bit odd that reading the cache on OSX (14MB) takes more
> than a minute whereas on Linux (6MB) it only takes 7 seconds. Obviously,
> the algorithms used in the pickle module are far from being O(n).... ;)

I appreciate your efforts to speed up cod generation process. This
specific patch
will not find its way to Py++ :-(. It is too dangerous:

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.

To make the long story short, after you modify the declaration tree Py++ is
responsible for generated code :-).

If it works for you fine, otherwise ...

Can you post your profiler results? May be we can find something that
could\should be fixed.

Thanks

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/