3 ms·

Sad to hear that. I don't use Safari, but maybe it cannot compete with the JS engines of Firefox and Chrome's version of the Webkit engine. This script reqiure

Sad to hear that. I don't use Safari, but maybe it cannot compete with the JS engines of Firefox and Chrome's version of the Webkit engine. This script reqiures a lot of computation in JS and communication between the website and the webworker (~300kb). Maybe Safari is unable to cope with this in a decent amount of time.

simonster 14y ago
I've seen emscripten-generated JS crash Safari before. It's not a performance issue; jsc is plenty fast and beats SpiderMonkey in most benchmarks. However, emscripten seems to exercise certain corners of JS that pose stability problems for jsc.
- olliej 14y ago
  Anyone want to test a webkit nightly? I don't have a desktop machine handy tight now to test on :( Or even just a bug report at bugs.webkit.org Thanks :)
  - tolmasky 14y ago
    Just tried it, crashes in the exact same way: 1. Hitting "Compile" does whatever it should do successfully. 2. Then hitting "Open PDF" opens a new tab which stalls out and crashes I would almost say its actually a PDF thing that is crashing Safari vs a JS thing. At least, that's what has happened consistently on my machine with latest Safari and WebKit nightly. Edit: However, taking the generated PDF from Chrome and dropping it into Safari loads it fine, so maybe it is a JS thing. Edit 2: Upon further inspection it appears the new tab is being opened with just a data URL representing the entire PDF. It wouldn't surprise me if that's the problem (Safari not being able to handle huge data as a URL). I recall running into a similar crash in MobileSafari because of that a while ago.
    - tolmasky 14y ago
      Yup, that is for sure it. I took the Chrome generated PDF, turned it into a data URL, then copy-pasted the data URL into Safari's URL bar. Crash. Drag and dropping the file itself into Safari, works fine.
      - azakai 14y ago
        Please file a bug, so they can fix it.
    - bstar77 14y ago
      Nice debugging, not a fan of making blanket assumptions when something isn't working as expected.
- bzbarsky 14y ago
  Which benchmarks are you looking at? And are they actually JSC vs SpiderMonkey or JSC+WebKit vs SpiderMonkey+Gecko? I.e. are they JS benchmarks or DOM benchmarks?
  - simonster 14y ago
    "Beats" might be too strong a word :). I guess the picture from AWFY 64-bit is that both have strengths and weaknesses but overall they're comparable.
    - bzbarsky 14y ago
      Yeah, on that set of benchmarks (the one that everyone is targeting hence not doing anything obviously stupid on), they are. The problem is that all of the JS engines involved have various failure modes in which they end up way slower than the others, though... We're talking 10x-1000x slower. And the problem with performance is it only takes your script hitting one serious performance bottleneck to make the speed of the rest of it not really matter. :( Hence my interest in testcases that point out such performance cliffs, so they can be removed.
dubcanada 14y ago
It crashes my Opera also. And this is a funny comment, Safari actually beats Firefox in most tests.

simonster 14y ago

I've seen emscripten-generated JS crash Safari before. It's not a performance issue; jsc is plenty fast and beats SpiderMonkey in most benchmarks. However, emscripten seems to exercise certain corners of JS that pose stability problems for jsc.

olliej 14y ago
Anyone want to test a webkit nightly? I don't have a desktop machine handy tight now to test on :( Or even just a bug report at bugs.webkit.org Thanks :)
- tolmasky 14y ago
  Just tried it, crashes in the exact same way: 1. Hitting "Compile" does whatever it should do successfully. 2. Then hitting "Open PDF" opens a new tab which stalls out and crashes I would almost say its actually a PDF thing that is crashing Safari vs a JS thing. At least, that's what has happened consistently on my machine with latest Safari and WebKit nightly. Edit: However, taking the generated PDF from Chrome and dropping it into Safari loads it fine, so maybe it is a JS thing. Edit 2: Upon further inspection it appears the new tab is being opened with just a data URL representing the entire PDF. It wouldn't surprise me if that's the problem (Safari not being able to handle huge data as a URL). I recall running into a similar crash in MobileSafari because of that a while ago.
  - tolmasky 14y ago
    Yup, that is for sure it. I took the Chrome generated PDF, turned it into a data URL, then copy-pasted the data URL into Safari's URL bar. Crash. Drag and dropping the file itself into Safari, works fine.
    - azakai 14y ago
      Please file a bug, so they can fix it.
  - bstar77 14y ago
    Nice debugging, not a fan of making blanket assumptions when something isn't working as expected.
bzbarsky 14y ago
Which benchmarks are you looking at? And are they actually JSC vs SpiderMonkey or JSC+WebKit vs SpiderMonkey+Gecko? I.e. are they JS benchmarks or DOM benchmarks?
- simonster 14y ago
  "Beats" might be too strong a word :). I guess the picture from AWFY 64-bit is that both have strengths and weaknesses but overall they're comparable.
  - bzbarsky 14y ago
    Yeah, on that set of benchmarks (the one that everyone is targeting hence not doing anything obviously stupid on), they are. The problem is that all of the JS engines involved have various failure modes in which they end up way slower than the others, though... We're talking 10x-1000x slower. And the problem with performance is it only takes your script hitting one serious performance bottleneck to make the speed of the rest of it not really matter. :( Hence my interest in testcases that point out such performance cliffs, so they can be removed.

dubcanada 14y ago

It crashes my Opera also. And this is a funny comment, Safari actually beats Firefox in most tests.