Closed Bug 194308 Opened 22 years ago Closed 19 years ago

add option to disable fastload

Categories

(Core :: XPCOM, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Future

People

(Reporter: cathleennscp, Assigned: dougt)

References

Details

(Keywords: fixed1.8.1, memory-footprint)

Attachments

(3 files)

make it part of --disable-xul
Putting the XPCOM part under --disable-xul doesn't make sense.
dougt hasn't been updating this bug, but I emailed him the other week about
making it a --disable-xpcom-fastload option, and he agreed.

/be
moving minimo bugs to the new bugzilla product.
Component: XP Miscellany → General
Product: Browser → Minimo
Version: Trunk → unspecified
Blocks: 273568
Minimo may be using XUL now.  fastload seams like something you would want to
have.  brendan, is there any reason why I would want to disable fastload if I
was using XUL?
i do not think this is important anymore.
Assignee: dougt → nobody
Component: General → XPCOM
Product: Minimo → Core
Summary: [minimo] disable fastload → add option to disable fastload
Target Milestone: --- → Future
Version: unspecified → Trunk
Assignee: nobody → dougt
Attached patch patch v.1Splinter Review
removing the fastload, i see a small perf improvement.  it appears that writing to a flash-memory based file system is an very slow process.
Attachment #204642 - Flags: review?(benjamin)
Comment on attachment 204642 [details] [diff] [review]
patch v.1

r=me, assuming there's another patch which actually does something useful with this flag ;-)
Attachment #204642 - Flags: review?(benjamin) → review+
Attached patch xpcom patch v.1Splinter Review
Attachment #204698 - Flags: review?(benjamin)
Attachment #204698 - Flags: review?(benjamin) → review+
Checking in xpcom/build/nsXPComInit.cpp;
/cvsroot/mozilla/xpcom/build/nsXPComInit.cpp,v  <--  nsXPComInit.cpp
new revision: 1.227; previous revision: 1.226
done
Checking in xpcom/io/Makefile.in;
/cvsroot/mozilla/xpcom/io/Makefile.in,v  <--  Makefile.in
new revision: 1.85; previous revision: 1.84
done
Checking in configure.in;
/cvsroot/mozilla/configure.in,v  <--  configure.in
new revision: 1.1563; previous revision: 1.1562
done
Checking in config/autoconf.mk.in;
/cvsroot/mozilla/config/autoconf.mk.in,v  <--  autoconf.mk.in
new revision: 3.374; previous revision: 3.373
done

Fixed on trunk.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment on attachment 204642 [details] [diff] [review]
patch v.1

+MOZ_ARG_DISABLE_BOOL(xpcom-fastload,
+[  --disable-xpcom-fastload           Disable XPCOM fastload support],
+    MOZ_NO_FAST_LOAD=,
+    MOZ_NO_FAST_LOAD=1)

The logic is backwards.  Specifying --disable-xpcom-fastload will unset MOZ_NO_FAST_LOAD when it should set it.

Btw, --disable-xpcom-obsolete suffers from the same problem.
Attachment #204642 - Flags: superreview-
seawood, i just fixed both cases you mentioned.  

Checking in configure.in;
/cvsroot/mozilla/configure.in,v  <--  configure.in
new revision: 1.1564; previous revision: 1.1563
done
Attachment #222412 - Flags: review?
Attachment #222412 - Flags: approval-branch-1.8.1?
Attachment #222412 - Flags: review?(benjamin)
Attachment #222412 - Flags: review?
Attachment #222412 - Flags: approval-branch-1.8.1?(benjamin)
Attachment #222412 - Flags: approval-branch-1.8.1?
Attachment #222412 - Flags: superreview?(darin)
Attachment #222412 - Flags: review?(benjamin)
Attachment #222412 - Flags: review+
Attachment #222412 - Flags: approval-branch-1.8.1?(benjamin)
Attachment #222412 - Flags: approval-branch-1.8.1+
Keywords: fixed1.8.1
Comment on attachment 222412 [details] [diff] [review]
patch for 1.8 branch

It seems like there must be a lot of extra code that could be #ifdef'd away in a build with fastload disabled.  How about adding #ifdefs to those?  Or, is that a separate bug?

At any rate, this much looks good.  sr=darin
Attachment #222412 - Flags: superreview?(darin) → superreview+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: