Closed Bug 885786 Opened 11 years ago Closed 11 years ago

JavaScript is massively slower when run in extension than when run in web page

Categories

(Add-on SDK Graveyard :: General, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 880330

People

(Reporter: benjamin.j.mccann, Assigned: ejpbruel)

References

Details

(Keywords: perf)

Attachments

(1 file, 1 obsolete file)

Attached file test.html (obsolete) —
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36

Steps to reproduce:

Run the attached JavaScript in a browser extension and in a web page


Actual results:

It's crazy slow when running in a browser extension, but runs just fine in the web page


Expected results:

It should be as fast as running in a web page (or as running in my Chrome extension which doesn't have this problem)
Ben, the context is confusing. Can you provide more information about how you got this running? In a Jetpack panel? Or loaded into a tab?

Irakli, do you know if Jetpack panels run under a different privilege context than other web content?
Flags: needinfo?(rFobic)
Keywords: perf
Hi Dietrich, I was running it directly in the extension iteself. I.e. just in the exports.main which is the entry point for the extension. The example I uploaded is just the web page version which runs quickly, but if you copy/paste the same code into an extension you can see it runs much slower there. Let me know if there's anything else I can do to help reproduce. I could make an extension to show the issue if needed
Hi Dietrich, I was running it directly in the extension iteself. I.e. just in the exports.main which is the entry point for the extension. The example I uploaded is just the web page version which runs quickly, but if you copy/paste the same code into an extension you can see it runs much slower there. Let me know if there's anything else I can do to help reproduce. I could make an extension to show the issue if needed
Hi Dietrich, I was running it directly in the extension iteself. I.e. just in the exports.main which is the entry point for the extension. The example I uploaded is just the web page version which runs quickly, but if you copy/paste the same code into an extension you can see it runs much slower there. Let me know if there's anything else I can do to help reproduce. I could make an extension to show the issue if needed
Flags: needinfo?(rFobic)
Sorry, I don't know why my last comment got submitted multiple times. I can't find anyway to delete the duplicates :-p
I just tested using sdk/frame/hidden-frame and the performance was about half-way in between running in a web page and running in the extension directly
Here are some more detailed numbers. There are some pretty big differences here. I haven't been able to figure out how to get it to run as fast as in a web page yet.

webpage: 350ms
page-worker: 1650ms
frame/hidden-frame: 1800ms
extension: 6000ms
Just tried content/worker and it as similarly bad (5500ms)
Do you see similar results in Firefox stable and in Firefox nightly ?
Yep, I just downloaded Firefox nightly and it looks like it's the same there
Any chance we can get a reduced code example?
A script which counts characters in a string. It runs 50 times slower when run in an extension than when run in a webpage.
Attachment #765958 - Attachment is obsolete: true
Here you go. This simple example is about a dozen lines long and counts the number of characters in a long string 100 times. It takes 100 ms to run in a webpage and 5,000 ms to run in an extension.
Eddy, do you know if sandboxes have any issues with the JIT? This almost sounds like we're falling back on the interpreter, causing it to be much slower...
Flags: needinfo?(ejpbruel)
Priority: -- → P1
(In reply to Wes Kocher (:KWierso) from comment #14)
> Eddy, do you know if sandboxes have any issues with the JIT? This almost
> sounds like we're falling back on the interpreter, causing it to be much
> slower...

There shouldn't be, but that is something we can investigate. I'll put this on my todo list.
Assignee: nobody → ejpbruel
Flags: needinfo?(ejpbruel)
Any chance you've had an opportunity to investigate in the past couple of weeks? This is a really big issue for us and I'd love to keep the ball rolling on it.
Eddy, when could you take a look at this?
Flags: needinfo?(ejpbruel)
(In reply to Dave Townsend (:Mossop) from comment #17)
> Eddy, when could you take a look at this?

I should be able to take a first look at this on friday.
Flags: needinfo?(ejpbruel)
Hey Eddy, did you have a chance to look at this? I think it should be pretty easy to reproduce, but let me know if you have any trouble and there's anything I can do to help.
(In reply to Eddy Bruel [:ejpbruel] from comment #18)
> (In reply to Dave Townsend (:Mossop) from comment #17)
> > Eddy, when could you take a look at this?
> 
> I should be able to take a first look at this on friday.

sorry to ping you about this again, but just wanted to check in to see if you'll have a chance to look at this. it's a big issue for us and i can't figure out much we can do on our end. thanks!
any thoughts on what might be causing this?
(In reply to Ben McCann from comment #21)
> any thoughts on what might be causing this?

Hey Ben. My apologies for the lack of updates, since this is apparently blocking you.

I've spent some time on this, but I have not yet figured out what's causing it. However, I've been busy working on bug 899052 lately, so I have not spend as much time on this as I would have liked.

I'm still pretty busy, but I should be able to reserve a day to look into this next week. Can I reach you on irc somewhere?
Flags: needinfo?(ejpbruel)
Hi Eddy, thanks for the update. I've never really used IRC, but I'm on Google chat for most of the day. Would that work for you? My Google username is benjamin.j.mccann and I've added you on Google+. I'm in California, and it looks like you're in Amsterdam, so our timezones might be a bit different, but I'd be happy to try and find a time when we're both available if it helps.
(In reply to Ben McCann from comment #23)
> Hi Eddy, thanks for the update. I've never really used IRC, but I'm on
> Google chat for most of the day. Would that work for you? My Google username
> is benjamin.j.mccann and I've added you on Google+. I'm in California, and
> it looks like you're in Amsterdam, so our timezones might be a bit
> different, but I'd be happy to try and find a time when we're both available
> if it helps.

I could do thursday morning if you're available then? (That would be early in the evening for me)
(In reply to Eddy Bruel [:ejpbruel] from comment #24) 
> I could do thursday morning if you're available then? (That would be early
> in the evening for me)

Works for me. What time would you like to meet?
(In reply to Ben McCann from comment #25)
> (In reply to Eddy Bruel [:ejpbruel] from comment #24) 
> > I could do thursday morning if you're available then? (That would be early
> > in the evening for me)
> 
> Works for me. What time would you like to meet?

I could do as early as 9am. Assuming you're on the west coast, that's 6pm for me. I have a couple of hours. What I'd like to do is reproduce the problem, and ideally figure out what's causing it. Depending on what the problems turns out to be, I can then hopefully give you an ETA on a fix. Sounds good?
Great, sounds good to me. I'll be on Google chat then and you can ping me whenever you're ready.
Just to update folks who are following along, Eddy was able to reproduce this and had a couple of hypotheses, but wanted to test against FF nightly which we were both having trouble doing.

> im still compiling a fresh nightly, should be done soon
> on my current firefox however, i can reproduce the problem
> 15000ms
> thats bad
> catastrophically so :)
> at least youve given me a simple test case
> currently i have two hypothesises:
> 1. somehow extension code falls back to interpreter mode
> 2. somehow our string optimizations fail in extensions
> im also having problems running it on nightly
> weird
> i need to get a hold of some of the addons guys to see if i can get something > to run on nightly
> once I do that I can confirm whether were still seeing performance degradation on nightly
Eddy, any luck on getting the FF nightly to run?
(In reply to Ben McCann from comment #29)
> Eddy, any luck on getting the FF nightly to run?

I'm taking another look at this tomorrow.
(In reply to Ben McCann from comment #29)
> Eddy, any luck on getting the FF nightly to run?

Ok, so I can reproduce the problem on Nightly. I'm seeing massive slowdowns of more than 50x.

The next step is figuring out if this has something to do with the JIT being disabled for addon scripts.
This is caused by bug 880330.
Thanks for the investigation Eddy! Should we mark this as a duplicate then?
Jep. Also, fwiw, that other bug is on top of my list. This is something the SDK team would like to see fixed asap, obviously.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Great. Thanks again!
(In reply to Eddy Bruel [:ejpbruel] from comment #34)
> Jep. Also, fwiw, that other bug is on top of my list. This is something the
> SDK team would like to see fixed asap, obviously.
> 
> *** This bug has been marked as a duplicate of bug 880330 ***

Also, all of the devtools using the Jetpack loader, right? :)
Now that the patch from https://bugzilla.mozilla.org/show_bug.cgi?id=880330 is in mozilla-central I tested the examples in https://bugzilla.mozilla.org/show_bug.cgi?id=916464 against latest-mozilla-central. So far no improvements of the performance. Is there anything else required to toggle the JIT for the Addon SDK?
(In reply to Thomas Oberndörfer from comment #37)
> Now that the patch from https://bugzilla.mozilla.org/show_bug.cgi?id=880330
> is in mozilla-central I tested the examples in
> https://bugzilla.mozilla.org/show_bug.cgi?id=916464 against
> latest-mozilla-central. So far no improvements of the performance. Is there
> anything else required to toggle the JIT for the Addon SDK?

There is still some work to be done before we can toggle the JIT in sandboxes. The patches that landed so far refactor ContextOptions to be a struct rather than a bitfield. The next step will be to move most flags from the context to the runtime, and then to move the JIT flags to the compartment. This will allow us to set the JIT flags on a per sandbox basis.

The hard part here is of course updating all existing consumers as we go along (preferably without introducing any regressions!).

Hope that helps!
Depends on: 880330
Depends on: 934418
Depends on: 934419
Depends on: 939562
No longer depends on: 934418
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: