>   I'll try to modify the code so that .pr file may not have to be
>  compressed and see if how much we gain.

Ah nice, that happens to be what I'm working on as well.
I've got some patches to play around with which disable either zipping
the project file or the bundle, and subsequently only delivers the .pr
file (Oh, the confusion, naming both the project bundle as well as the
project file <pr-name>.pr).

Hopefully tomorrow I'll give an account of my performance findings
while testing different combinations of zipping. As an intermediate
report, totally unzipping a .pr file almost doubles loading on my mac,
 but loading on an XO has  been slightly disappointing. Small projects
were up to 2 times as fast to load, but the bigger ones were a quarter
as slow.

Attached are some other patches related to zipping:

1) fileIn fix
In order to load a project bundle with an non-zipped .pr file in it,
you've got to change the type of stream to create in
projectStreamFromArchive from RWBinaryOrTextStream to
MultiByteBinaryOrTextStream, since that's the class the project
loading methods are defined on.

2) asUnzippedStream
changes uptoEndWithProgressBar to uptoEnd in the method with the same
name as the changeset to get a 20 percent increase in project loading.

These patches are part of my 'one patch per day' project, that will
run from now till into the not at all to distant future.

/Ties
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fileIn fix.1.cs
Type: application/octet-stream
Size: 553 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080407/cdce977b/fileInfix.1.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asUnzippedStream.1.cs
Type: application/octet-stream
Size: 1023 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080407/cdce977b/asUnzippedStream.1.obj