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)
Add-on SDK Graveyard
General
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)
183.82 KB,
text/plain
|
Details |
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)
Comment 1•11 years ago
|
||
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
Reporter | ||
Comment 2•11 years ago
|
||
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
Reporter | ||
Comment 3•11 years ago
|
||
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
Reporter | ||
Comment 4•11 years ago
|
||
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)
Reporter | ||
Comment 5•11 years ago
|
||
Sorry, I don't know why my last comment got submitted multiple times. I can't find anyway to delete the duplicates :-p
Reporter | ||
Comment 6•11 years ago
|
||
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
Reporter | ||
Comment 7•11 years ago
|
||
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
Reporter | ||
Comment 8•11 years ago
|
||
Just tried content/worker and it as similarly bad (5500ms)
Comment 9•11 years ago
|
||
Do you see similar results in Firefox stable and in Firefox nightly ?
Reporter | ||
Comment 10•11 years ago
|
||
Yep, I just downloaded Firefox nightly and it looks like it's the same there
Comment 11•11 years ago
|
||
Any chance we can get a reduced code example?
Reporter | ||
Comment 12•11 years ago
|
||
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
Reporter | ||
Comment 13•11 years ago
|
||
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
Assignee | ||
Comment 15•11 years ago
|
||
(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)
Reporter | ||
Comment 16•11 years ago
|
||
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.
Assignee | ||
Comment 18•11 years ago
|
||
(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)
Reporter | ||
Comment 19•11 years ago
|
||
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.
Reporter | ||
Comment 20•11 years ago
|
||
(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!
Reporter | ||
Comment 21•11 years ago
|
||
any thoughts on what might be causing this?
Flags: needinfo?(ejpbruel)
Assignee | ||
Comment 22•11 years ago
|
||
(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?
Assignee | ||
Updated•11 years ago
|
Flags: needinfo?(ejpbruel)
Reporter | ||
Comment 23•11 years ago
|
||
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.
Assignee | ||
Comment 24•11 years ago
|
||
(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)
Reporter | ||
Comment 25•11 years ago
|
||
(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?
Assignee | ||
Comment 26•11 years ago
|
||
(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?
Reporter | ||
Comment 27•11 years ago
|
||
Great, sounds good to me. I'll be on Google chat then and you can ping me whenever you're ready.
Reporter | ||
Comment 28•11 years ago
|
||
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
Reporter | ||
Comment 29•11 years ago
|
||
Eddy, any luck on getting the FF nightly to run?
Assignee | ||
Comment 30•11 years ago
|
||
(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.
Assignee | ||
Comment 31•11 years ago
|
||
(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.
Assignee | ||
Comment 32•11 years ago
|
||
This is caused by bug 880330.
Reporter | ||
Comment 33•11 years ago
|
||
Thanks for the investigation Eddy! Should we mark this as a duplicate then?
Assignee | ||
Comment 34•11 years ago
|
||
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
Reporter | ||
Comment 35•11 years ago
|
||
Great. Thanks again!
Comment 36•11 years ago
|
||
(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? :)
Comment 37•11 years ago
|
||
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?
Assignee | ||
Comment 38•11 years ago
|
||
(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!
Updated•9 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•