I have uploaded a fully optimized VACPP Warpzilla 0.6 (aka IBM Web
Browser) to mozilla.org:
ftp://ftp.mozilla.org/pub/mozilla/releases/mozilla0.6/mozilla-i386-pcos2-vacpp-opt-0.6.zip
Before you ask, the main reason we chose 0.6 is because we wanted a
known stable entity to work with, and all of the concepts are the same.
The code we wrote will go into the trunk and future milestones. We also
chose it for the more obvious reason that IBM pays my bills :)
This build reflects a lot of work that has been done by my team to
improve the performance of the VACPP Warpzilla.
Here is a quick summary:
1. We have rewritten xptcstubs and xptcinvoke in XPCOM. This was
necessary to enable optimization in the compiler. There was code in
these functions that did not work when the code was optimized. We also
hand tuned these functions to make them faster. Thanks to Jeff Jones and
Javier Pedemonte for these changes.
2. NSPR has some atom functions that were either inline assembly or C
runtime calls on all platforms except OS/2. On OS/2, we were using the
generic NSPR implementation which were VERY slow. We have implemented
them in assembly.
BIG NOTE - I did NOT include the RAM semaphores in this build. I want to
determine whether or not the key performance issue was the
PR_Lock/PR_Unlock code itself or the face that the atom code was calling
it too much. If you want to try the new atom code AND the ramsems, use
the NSPR4.ZIP which is at:
ftp://ftp.software.ibm.com/ps/products/warpzilla/nspr4.zip
3. We have modified some of the flags used in the build. We have added
the /Gx flag when we compile C++. Because Mozilla does not use C++
exceptions, this is not needed, and it reduces code size. Also, we have
added the /G5 flag in NSPR - it was missing this optimization. We are
using the /Gl function in conjunction with the /OPTFUNC flag on the
linker to reduce code size.
4. We have fully optimized the build using the /O+ option. In doing
this, we found at least two compiler bugs (probably more). The first one
requires a fix for the compiler. You will know that you have this bug if
the build hangs compiling nsMsgMD5.cpp in mailnews. The second bug has
not been fixed at the time of this writing, so as a result, we are
unable to optimize the mozilla/security/nss/lib/freebl directory.
5. We are using the new version of LXLITE (1.3.1) to reduce the size of
the DLLs.
Please note that THIS VERSION HAS BUGS! Some people have said it is less
stable, and we have at least found a problem with the rounding of values
when Document Done is displayed.
Please DON'T report bugs on this in Bugzilla. Please report them here.
We will continue to look at this build to get as many bugs fixed as we
can. Most of them will be bugs in the compiler, so we will want to find
them as soon as possible since they will most likely affect trunk builds
as well.
IMPORTANT: You CAN'T share profiles with 0.6 and later builds. Make sure
you create a new profile to use this.
Thanks for your support.
Mike Kaply
IBM
