On 14.01.2007 22:22, Eric Sunshine wrote: > - It may not necessarily be true that breaking the bindings apart > into smaller modules would improve build time (in fact, it might > lengthen it). A couple years ago, when considering the same issue, I > ran CS/scripts/perl5/cswigpl5.inc through the C++ preprocessor to see > how much actual code was being fed to the compiler. At the time, the > result was >12MB. So, that's 12MB of source code the compiler has to > handle. It's a lot of code. 12MB is 12MB whether contained in one > file or twenty. The Swig-generated files have grown a good deal since > my earlier testing.
Whether or not you have X MB split over multiple files makes a difference depends on the RAM you have - if all the data structures etc. the compiler generates fit into your RAM in one go, you're fine. However, if they don't, and compiling the One Big File results in thrashing, a compile may take significantly longer than the sum of all the smaller files, which fir into RAM completely each. And I heard people complaining about the bindings compile filling up all the RAM more than once. > - As a rough heuristic, I might suggest creating one binding module > per top-level CS header directory. For instance, csutil, csgeom, > iutil, iengine, ivaria, etc. This won't be a perfectly balanced break- > down, however, it is important to factor the "ifoo" stuff into the > equation since the SCF interfaces account for a significant portion > of the bulk of the Swig-generated code. It may not be perfectly balanced, but it's an IMO sensible splitting: you can determine the module in which a class/interface is if you know it's C++ header - which in turn can be found out with the API docs. >> Then also there is a detail that could be attacked at the same time, >> right now cspython links in the _cspace swig generated library, also >> cel's blcelc is linking in _cspace and _blcelc libraries. This is >> convenient for distribution but i'm not sure about whether its best >> approach, in any case i'd like to know if other languages are doing >> similar or they use the swig generated dlls. (in python the dlls are >> only used from pure python apps, if using embedded code the versions >> linked in are used instead). If the SWIG glue code was in a shared library, it could be shared between the CS plugin and python module. (The py glue code is actually in a shared library if shared libs are enabled.) -f.r.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Crystal-main mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/crystal-main Unsubscribe: mailto:[EMAIL PROTECTED]
