Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


On 6 March 2012 11:55, Michael Meeks <michael.meeks@suse.com> wrote:
       I guess the other big win there to get the time down to seconds would
be to get idlc/'s idlcpp to compile lots of these IDL files at once.

Not really. On Linux this may be true but with cygwin processing idl
files is not the main issue.
If you look what is happening in *api, make is:
1, touching .d files
2, processing .idl files
3, again touching .d files
4, creating .rdb files and something else maybe
5, copying .idl .hpp .hdl files to solver

On cygwin, most of the time takes 5, and touching files is also slow.
The real work there in 2, and 4, is +-fast and you won't save much by
making it faster.

That is assuming that some large chunk of the overhead on windows comes
from several thousand invocations of the same small tool :-)

This seems to be true but idlc is called less than touch and much less than cp.
So, maybe next improvement would be to call cp once for all files from
the same directory.

       Would that interest you Matus ? or should I file an easy hack ?

No. You can file an easy hack, but do not expect big difference.

Maybe you could file an easy hack for improving gbuild's Package.mk,
so that we would copy all files to the same directory at once.
It would be great, I think, to have some other person who would
understand our makefiles,
but I don't know how easy that is. It takes time first but then I
think it's easy.
Should be possible to make the directory in solver depend on files we
want to copy there and create rule for that.

Best,
Matus

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.