Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4FAA710D.1030605@a-w-f.de>
Date: Wed, 09 May 2012 15:28:45 +0200
From: Andre Fischer <af@a-w-f.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Why is creating pack sets so slow?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I would like to share some numbers (and some rants) with you.

Now that the release is done, I looked a little closer at why the
creation of pack sets takes so long (the things that are created in 
main/instsetoo_native).  Here are some numbers for the
creation of the archive on Windows7.  The absolute numbers are
entirely unrepresentative but I think they illustrate the general
problem.

The whole process of creating the archive pack set took 5 minutes and
29 seconds (=329s).  This includes:

- unzipping of 61 archives: 42s

- copying of 3014 files to temporary directory: 105s

- changing access privileges of files in temp. directory: 79s

- creating the archive pack set: 31s

- deletion of temporary files: 7s


I think that everything except the 31s for creating the actual archive
is not really necessary.  42s+105s+79s+7s=233s or 71% out of the
total of 329s are spent on unzipping archives that have been created
earlier in the build process and on copying files to yet another
directory that have already been copied (delivered) once or twice into
main/solver/.

A lot of time could be saved if

a) we would not create zip files in some modules (like helpcontent2)
just to unpack them (before the packing them again into the final
archive.)

b) our modules would deliver files to places that could directly be
used in the final packaging.  (Which, as I thought, was one of the key
ideas of the "new" gbuild system.  What became of that?)


I know that it will not really be that simple.  Localization files for
example can not be copied into their final place for all languages at
the same time.


I hope that I will find the time to come up with some concrete ideas
of how to improve the current system (I have no intention to completely
rewrite it).

Comments, suggestions and explanations (about the status quo) are welcome.

Andre