As was said before, the load time is still slow. Average start to home page is still
26 seconds, (Windows XP start to load of same page is
six seconds, EMX build 16 seconds). The SSL does work for me although it is much
slower than the 091 build and some sites don't work
correctly.
Speedwise, large pages are rendered much quicker than NS461, although I can't see a
perceptible difference over the 091 build.
Steve
On Tue, 26 Jun 2001 22:46:06 -0500, Michael Kaply wrote:
-->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
-->
