Reduce memory usage for compilation of dolfin extension module

GNW: This has got to the point that I'd call it a bug.

MER: Copied from mailinglist 17/05/2011:

I have noticed that too. My dolfinPYTHON_wrap.cxx is now 6 MB large. A couple
of years ago I tried to trim it from some 5Mb to 3ish. But I guess it has
steadily increased. I do not think there are any magic bullet to decrease it
drastically more than doing something in the line you suggests.

The SWIG interface is built so it should (in theory) be possible to generate,
one extension module for each "kernel module". We have a pre_foo.i and a
post_foo.i where all the module specific specializations are done. These
together with global typemap files are more or less what is used to generate
the extention module. The global files can be shared among the splitted
extension modules.

I wrote in theory because it has actually not been done. I predict all kindoff
problems, with circular dependencies and lack of correct forward declarations
beeing the worst ones. I also think it will result in an overall larger memory
signature during runtime. This is because of duplication of generated code in
each of the extension modules.

The issue of splitting the dolfin extension module has come up before, and
there are compelling reasons to do it. Can Kent and maybe Ola enlight us on
more potential issues with doing this (in addition to someone(TM) actually
have to do it... :P).

Johan

On Tuesday May 17 2011 07:12:47 Kristian Ølgaard wrote:
> Hi,
>
> Lately I've noticed that compiling the Swig generated cpp file exhaust my
> memory (1GB) and uses up to 60% of the swap which means compiling DOLFIN
> takes around 30min.
> In addition, the single cpp file represents a bottleneck when
> compiling using multiple processes.
>
> Will it be possible to let Swig generate multiple files instead, and
> link those into a
> Python module?
>
> Kristian