Closed
Bug 129719
Opened 23 years ago
Closed 22 years ago
Add OS/2 specific turbo mode
Categories
(Core Graveyard :: QuickLaunch (AKA turbo mode), defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: mkaply, Assigned: mkaply)
Details
(Whiteboard: fixed1.3)
Attachments
(1 file, 1 obsolete file)
10.72 KB,
patch
|
jhpedemonte
:
review+
asa
:
approval1.3+
|
Details | Diff | Splinter Review |
We have created an OS/2 specific turbo mode.
Rather than attempting to prelaunch the browser, it loads necessary DLLs and
touches the code.
We found this is a very effective way to improve startup without the problems
associated with turbo mode.
We'd like to add a new directory under xpfe/bootstrap called OS2TURBO which
contains this code.
The code generates a standalone EXE that acts as daemon and preloads the DLLs.
Mike, why is this mine? Can't you just go ahead and add that directory? Or did
I get it just because I'm the default assignee for QuickLaunch?
Assignee | ||
Comment 2•23 years ago
|
||
Because you are the default assignee and because I wanted your opinion :)
Do you have any idea why this type of approach wasn't considered for windows?
Assignee: law → mkaply
Simply loading the .dlls wasn't a big enough win. If we don't do the funky
opening of a Nav window (to initialize services, prime the xul cache, etc.) then
it just didn't buy us enough.
Assignee | ||
Comment 4•23 years ago
|
||
For our corporate users and some of our regular users, turbo mode is just too
much. We need something simpler.
Here is the text from the C file:
This program implements a module preloader for the OS/2 version of the Mozilla
Web Browser.
The program operates by way of DosLoadModule of a pre-defined list of modules.
In addition to DosLoadModule, the program then queries the ordinal entry points
of the modules and then accesses the address of each entry point in order to
cause the memory page of that entry point to become paged-in and resident in
memory. In this way the program preloads much of the modules used in MOZILLA
execution. After preloading the modules, then the program suspends execution
by infinite wait on a named semaphore. In this manner, the MOZTURBO holds the
MOZILLA modules in memory before and after the execution of MOZILLA.
The UNLOAD option is provided to allow a second invocation of this program to
communicate with, and signal termination of, the first instance of the program.
This allows DETACH MOZTURBO -LOAD to be used to load, then as required,
MOZTURBO -UNLOAD will cause the detached instance of MOZTURBO to unload and
exit. Both -UNLOAD and -LOAD may be specified, to allow a concurrent unload
and reload of modules. This might be used to, for example, reload MOZILLA
modules from a different path.
Notes: As currently implemented, MOZTURBO loads modules from LIBPATH. This
may not be the module location loading as used by MOZILLA. Need to check this.
The list of module names to be loaded is 'hardcoded' in the file mozturbo.h
and specified to the program by means of #include <mozturbo.h>. This list of
files need to be reviewed. Perhaps a less hardcoded list should be implemented.
Assignee | ||
Comment 5•23 years ago
|
||
dprice:
Thought you might find this interesting since you started something
similar for Windows.
Assignee | ||
Comment 6•22 years ago
|
||
OK, I've cleaned up the code a lot and it should be good to go.
Basically rewrote to be prettier and do a lot less work, but give the same
gain.
In our tests, this basically cut our start times in half. Not as good as Moz
turbo, but safer as far as we are concerned.
Attachment #91027 -
Attachment is obsolete: true
Assignee | ||
Updated•22 years ago
|
Attachment #116131 -
Flags: review?(pedemont)
Updated•22 years ago
|
Attachment #116131 -
Flags: review?(pedemont) → review+
Comment 7•22 years ago
|
||
Comment on attachment 116131 [details] [diff] [review]
New implementation
r=cls on the Makefile change
Assignee | ||
Comment 8•22 years ago
|
||
Checked in
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Whiteboard: iwb2.0.1
Assignee | ||
Comment 9•22 years ago
|
||
Comment on attachment 116131 [details] [diff] [review]
New implementation
Again, last minute but totally OS/2 only.
Mainly wanting to get this stuff in 1.3final because it is less work to pull it
over to our browser release.
Totally OS/2 only.
Thanks!
Attachment #116131 -
Flags: approval1.3?
Comment 10•22 years ago
|
||
OS/2 user please verify
Comment 11•22 years ago
|
||
Comment on attachment 116131 [details] [diff] [review]
New implementation
a=asa (on behalf of drivers) for checkin to 1.3
Attachment #116131 -
Flags: approval1.3? → approval1.3+
Assignee | ||
Updated•22 years ago
|
Whiteboard: iwb2.0.1 → fixed1.3
Updated•12 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•