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)

x86
OS/2
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: mkaply, Assigned: mkaply)

Details

(Whiteboard: fixed1.3)

Attachments

(1 file, 1 obsolete file)

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?
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.
Attached patch OS/2 specific turbo mode (obsolete) — Splinter Review
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.
dprice: Thought you might find this interesting since you started something similar for Windows.
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
Attachment #116131 - Flags: review?(pedemont)
Attachment #116131 - Flags: review?(pedemont) → review+
Comment on attachment 116131 [details] [diff] [review] New implementation r=cls on the Makefile change
Checked in
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Whiteboard: iwb2.0.1
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?
OS/2 user please verify
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+
Whiteboard: iwb2.0.1 → fixed1.3
verify - this is working
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: