GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-06-22) - page 1 of 10
 
___________________________________________________________________
Chrome 59 with TurboFan is Sometimes Slower than 58
49 points by jotto
https://www.prerender.cloud/blog/2017/06/22/chrome-59-is-sometim...
s-sometimes-slower
___________________________________________________________________
 
homakov - 1 hours ago
If you can make it eat less memory, go make it 2x slower im fine
with it.
 
  PetahNZ - 42 minutes ago
  Why? memory is cheap.
 
    [deleted]
 
chickenbane - 1 hours ago
This page does not show Chrome being 59 being slower.  Rather, it
shows a contrived bench running 38% slower.  Interestingly, it also
shows their site running 32% faster.Given the V8 team has
explicitly stated the plan to optimize for real websites rather
than synthetic benchmarks [1] these results look completely
appropriate and desirable.  Good work V8
team!https://blog.chromium.org/2017/04/real-world-javascript-
perf...
 
  randyrand - 1 hours ago
  Perhaps the title changed? It now says chrome is sometimes
  slower.
 
    [deleted]
 
artursapek - 1 hours ago
I wonder why these guys are using Chrome for this? I've had no
problem pre-rendering React using a simple node process and
ReactDOMServer.renderToString();
 
  jotto - 1 hours ago
  Because rendering in a Node process is more complicated when
  async state is involved - using a browser eliminates that
  complexity. For simpler apps without any async state (AJAX or
  WebSockets), a Node process may suffice.
 
    mcintyre1994 - 48 minutes ago
    Dumb question because I have very little node experience - I've
    been doing a node course and it uses a lot of async stuff
    server side, eg for everything that hits the database (using
    promises). Why wouldn't you just do that for your async state
    when you render server side?
 
      jotto - 20 minutes ago
      You could indeed do that, it's just more work. The beauty of
      server-side rendering a React app in a headless browser is
      that since the environment is the same as what the app was
      originally designed for (a browser), things _just work_.For
      example: you load the app in your headless browser and let it
      load as would in any browser. The browser fires some events
      and XHR/WebSocket requests and you can cleanly wait for them
      to finish as opposed to doing something like this:
      https://techbrunch.gousto.co.uk/2016/10/10/isomorphic-
      react-... which requires you to do some extra configuration
      in your app to help support a Node environment.TL;DR:
      ReactDOMServer.renderToString won't wait for your async
      requests to finish, you need them to execute and finish
      before you call renderToString
 
  diek - 35 minutes ago
  After reading their 'How It Works' page, it looks like they load
  the DOM into headless Chrome, let all the JavaScript events fire,
  wait for rendering to complete, and then serialize the DOM
  afterwards.  Whereas with just rendering the React component
  you're getting the resulting HTML but you're not seeing the
  effect of actually executing any referenced JavaScript and the
  resulting DOM how a browser would see it.
 
fntd - 2 hours ago
So it is slower in a benchmark that doesn't represent any real
world problems, while an actual app performs much better?Isn't that
exactly what they were going for?
 
  gsnedders - 2 hours ago
  Yes. It was a very deliberate, conscious decision to not care
  about the benchmarks, marketing be damned; some of that was a
  belief the V8 had historically become overfit to them.
 
  eecc - 1 hours ago
  Exactly, and an attention whore clickbait site tries to drum up a
  case for views. Usual travesty
 
dacohenii - 1 hours ago
Here's an interesting talk about optimization and JIT compilation
in V8: https://www.youtube.com/watch?v=p-iiEDtpy6I
 
StillBored - 2 hours ago
The problem with javascript JIT's is that benchmarks which run for
tens of a second in a tiny piece of code are not reflective of
general usage patterns. So the quality of the initial pass
(baseline in Firefox) is likely more important. Worse, given fairly
dynamic code paths, the system can get into a situations where it
is cycling between optimization targets and spends a lot of time
running sub-optimal code and entering/exiting the JITed code, or
the JIT/compiler itself.Anyway, there are so many engineering trade
offs its like a big water balloon, squeeze it here and it gets
faster in this spot, but slows down somewhere else. When, what you
really need is a way to let some of the water out of the balloon.