openvrml-develop

[openvrml-develop] build-time memory consumption

[Sam H. <sa...@zo...>]

   Hello,

   I am the Debian maintainer for OpenVRML and I am having great trouble
getting it to build on all our architectures, because of g++'s insane
memory usage when lots of templates are involved.

   I know the problem lies mostly with g++, but if anyone with the
skills could have a look at browser.cpp and vrml97node.cpp in the
src/libopenvrml/openvrml/ directory, it would be much appreciated.
There must be a way to split these files so that g++'s memory usage
drops below 100MB (currently 150MB for browser.cpp and 350MB for
vrml97node.cpp on my x86 computer).

Best regards,
-- 
Sam.

Re: [openvrml-develop] build-time memory consumption

[Braden M. <br...@en...>]

Sam Hocevar wrote:
>    Hello,
> 
>    I am the Debian maintainer for OpenVRML and I am having great trouble
> getting it to build on all our architectures, because of g++'s insane
> memory usage when lots of templates are involved.
> 
>    I know the problem lies mostly with g++, but if anyone with the
> skills could have a look at browser.cpp and vrml97node.cpp in the
> src/libopenvrml/openvrml/ directory, it would be much appreciated.
> There must be a way to split these files so that g++'s memory usage
> drops below 100MB (currently 150MB for browser.cpp and 350MB for
> vrml97node.cpp on my x86 computer).

The problem with breaking a lot of this stuff up into multiple files is 
that it results in unnecessarily exposing symbols. Nearly everything in 
vrml97node.cpp is implementation details with a single exposed entry 
point. And while there are some small parts of browser.cpp that could 
probably be broken out, the overwhelming majority of its heft is also 
implementation details that should not be exposed.

Breaking stuff up means more private header files (yuck) and massaging 
the linker to keep from unnecessarily exposing symbols--and my 
impression is that libtool's support for that is rather weak.

Note that the code in vrml97node.cpp will be broken out into its own 
dlopen'd module in the future. (Probably not in the 0.16 time frame; but 
very likely for 0.17.) The plan is for these (and other) node 
implementations to live in their own modules through which the supported 
node set can be easily extended.

Braden

Re: [openvrml-develop] build-time memory consumption

[Andrew G. <an...@ok...>]

Braden McDaniel wrote:

> Sam Hocevar wrote:
>
>>    Hello,
>>
>>    I am the Debian maintainer for OpenVRML and I am having great trouble
>> getting it to build on all our architectures, because of g++'s insane
>> memory usage when lots of templates are involved.
>>
>>    I know the problem lies mostly with g++, but if anyone with the
>> skills could have a look at browser.cpp and vrml97node.cpp in the
>> src/libopenvrml/openvrml/ directory, it would be much appreciated.
>> There must be a way to split these files so that g++'s memory usage
>> drops below 100MB (currently 150MB for browser.cpp and 350MB for
>> vrml97node.cpp on my x86 computer).
>
>
> The problem with breaking a lot of this stuff up into multiple files 
> is that it results in unnecessarily exposing symbols. Nearly 
> everything in vrml97node.cpp is implementation details with a single 
> exposed entry point. And while there are some small parts of 
> browser.cpp that could probably be broken out, the overwhelming 
> majority of its heft is also implementation details that should not be 
> exposed.
>
> Breaking stuff up means more private header files (yuck) and massaging 
> the linker to keep from unnecessarily exposing symbols--and my 
> impression is that libtool's support for that is rather weak.
>
> Note that the code in vrml97node.cpp will be broken out into its own 
> dlopen'd module in the future. (Probably not in the 0.16 time frame; 
> but very likely for 0.17.) The plan is for these (and other) node 
> implementations to live in their own modules through which the 
> supported node set can be easily extended.
>
> Braden
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop

I think vrml97node.cpp could be split up if there were two registry 
functions (have a register_node_classes1() and a 
register_node_classes2()). This would break the file into 2 smaller ones 
without the need for additional exported functions (except for the extra 
register_node_classes)

I think browser.cpp is probably taking an extra long time now because it 
is now inlining two .cpp files (the parsers) instead of just the one. 
However, that is a tricky one because the parsers refer to non-exposed 
symbols within browser.cpp.

Re: [openvrml-develop] build-time memory consumption

[Braden M. <br...@en...>]

Andrew Grieve wrote:

 > I think vrml97node.cpp could be split up if there were two registry
 > functions (have a register_node_classes1() and a
 > register_node_classes2()). This would break the file into 2 smaller
 > ones without the need for additional exported functions (except for
 > the extra register_node_classes)

I'm not happy with this solution because the split would carry over into 
the modules, yielding two modules instead of one. This is a rather ugly 
change to runtime characteristics to solve a compile-time problem.

Braden

PS: Please be more conscientious in your quoting.