Ok, I run execmode against mozilla:
This is the output:
======================
K:\OS2PROG\ONLINE\WARPZILLA>execmode -sp -s *.exe *.dll
ExecMode v1.0 - Single processor execution mode utility
ACTIVATED OPTIONS:
SINGLE-PROCESSOR files option.
SUBDIRECTORY searching option.
FILES MODIFIED:
bin\dirver.exe (modified)
bin\mozilla.exe (modified)
bin\nsinstall.exe (modified)
bin\nsTestSample.exe (modified)
bin\psm.exe (modified)
bin\regchrome.exe (modified)
bin\regExport.exe (modified)
bin\regxpcom.exe (modified)
bin\timebombgen.exe (modified)
bin\vreg.exe (modified)
bin\xpcshell.exe (modified)
bin\xpidl.exe (modified)
bin\xpt_dump.exe (modified)
bin\xpt_link.exe (modified)
107 files analyzed, 14 files MODIFIED.
======================
Now, mozilla loads and creates a new profile.
I still have to do some more testing, but it seems fast!
How will the limitation to one CPU change performance?
Robert
Michael Kaply schrieb:
>
> Do you have the utility that forces an EXE to bind to one processor? I did not run
>that against
> this version, but I have in previous ones.
>
> Can you try that?
>
> I'll try to find an SMP machine to check out.
>
> Thanks
>
> Mike Kaply
> IBM
>
> Robert Henschel wrote:
>
> > Hi,
> >
> > I just downloaded the optimized VACPP 0.6 and got the following problem:
> >
> > I have WSEB with Fixpack 2 on SMP with 2 Intel Celeron. (no kernel
> > fixes, just fixpack 2)
> >
> > It starts loading, displays the "IBM Web Browser" logo and then hangs
> > the system. I can not even move the mouse or CAD.
> >
> > Just to let you know...
> >
> > Robert Henschel
> >
> > Michael Kaply schrieb:
> > >
> > > 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
