377437 - Consider disabling obsolete string API support for mozilla 1.9

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Benjamin Smedberg]

We have the ability to stop supporting the obsolete string API using a configure flag. This has a significant runtime performance benefit because it reduces the size of all strings, and it removes all the checking for the obsolete vtables.

This means that code which was compiled against the (frozen!) gecko 1.4 SDK will crash. Code which is compiled against the 1.7 or later SDKs will work correctly (since it uses the C-export string API). I think we should make this tradeoff, because the performance benefits are... significant.

Comment 1

[Benjamin Smedberg]

Attachment: Disable abiv1, rev. 1

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It seems like this has the potential to break a lot of things.  Do we have any idea of what's compiled against those old SDKs?  The Java plugin?  Eclipse stuff?

(Would there be any Firefox-specific stuff compiled against it?  I'd guess not, but I'm not sure.)

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #2)
> (Would there be any Firefox-specific stuff compiled against it?  I'd guess not,
> but I'm not sure.)

Binary extensions?

Comment 4

[Benjamin Smedberg]

I did a very unscientific survey of various plugins and extensions about 6 months ago. None of them were using the 1.4 SDK. Most extensions were using internal linkage, and most plugins were using frozen linkage or the scriptable NPAPI.

The only real concern for me is private/intranet/special-market plugins that might be very old. But it seems unlikely to me that those kinds of plugins would be using gecko-specific interface calls.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 261511 [details] [diff] [review]
Disable abiv1, rev. 1

Well, better off trying sooner than later.  sr=dbaron

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(Though maybe you want to leave the two lines that you're removing in case we, or some distributor, wants to switch it back on.)

Comment 7

[Darin Fisher]

Comment on attachment 261511 [details] [diff] [review]
Disable abiv1, rev. 1

I suspect that this will cause a crash for any users who has Google Desktop Search installed (which is built against the Mozilla 1.4 SDK), but if you want to make this change, go for it.

Comment 8

[Benjamin Smedberg]

Fixed on trunk.

Comment 9

[Steve Snyder]

Another data point.

Tested with the V1 string ABI disabled in v1.8.1.4, SeaMonkey v1.1.2 seems to work well.

The only drawback seen is that the RoboForm plug-in ("roboform-seamonkey.xpi", from http://www.roboform.com/browsers.html) refuses to work with SM.  It seems that the plug-in can't correctly determine the SM version number when the ABI is disabled.

Comment 10

[Boris Zbarsky [:bzbarsky]]

So how did this affect our perf metrics?

Comment 11

[Benjamin Smedberg]

Linux showed a definite 2-3% improvement in Tp2 and Ts. Windows didn't seem to move at all, which is weird. Mac Tp improved, though I'm not sure it was because of this checkin: the date seems to be off a bit.