3 ms·

"Their own JavaScript engine" is Mozilla SpiderMonkey 91. https://gitlab.gnome.org/GNOME/gjs/blob/master/doc/Home.md https://gitlab.gnome.org/GNOME/gjs/blob/ma

"Their own JavaScript engine" is Mozilla SpiderMonkey 91. https://gitlab.gnome.org/GNOME/gjs/blob/master/doc/Home.md https://gitlab.gnome.org/GNOME/gjs/blob/master/doc/Home.md It appears to be broadly competitive with V8. https://www.anandtech.com/show/16078/the-2020-browser-battle-surfing-with-speed/2 https://www.anandtech.com/show/16078/the-2020-browser-battle...

pjmlp 4y ago
Maybe it is competitive now, it hasn't always been like that. https://gitlab.gnome.org/GNOME/gjs/-/issues/231 https://gitlab.gnome.org/GNOME/gjs/-/issues/231 https://gitlab.gnome.org/GNOME/gjs/-/issues/361 https://gitlab.gnome.org/GNOME/gjs/-/issues/361 https://feaneron.com/2018/04/20/the-infamous-gnome-shell-memory-leak/ https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem... Just to give you a taste of the issues. When I complain about something, usually it is based on experience and knowledge. And if I wanted to have a desktop where JavaScript gets used everywhere I would buy a Chromebook instead.
- the_why_of_y 4y ago
  My reading is that performance problems are caused by interactions between reference-counted GObjects and tracing GC, nothing to do with "not having a V8 class implementation". > https://gitlab.gnome.org/GNOME/gjs/-/issues/361 https://gitlab.gnome.org/GNOME/gjs/-/issues/361 Now what can we learn here? Well, the most important lesson is that getting properties from GObjects seems to be very expensive and a major bottleneck [...] Also generally (and as expected), recursive processes like Clutters allocation machinery round tripping between C and JS land are a bad idea and should probably avoid JS land altogether > https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem... This fix is strictly specific to GObjects wrapped by GJS
  - pjmlp 4y ago
    From my point of view, the whole experience end to end counts as having a V8 class implementation, and not the bare bones runtime. ChromeOS isn't only V8 without anything else.

pjmlp 4y ago

Maybe it is competitive now, it hasn't always been like that. https://gitlab.gnome.org/GNOME/gjs/-/issues/231 https://gitlab.gnome.org/GNOME/gjs/-/issues/231 https://gitlab.gnome.org/GNOME/gjs/-/issues/361 https://gitlab.gnome.org/GNOME/gjs/-/issues/361 https://feaneron.com/2018/04/20/the-infamous-gnome-shell-memory-leak/ https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem... Just to give you a taste of the issues. When I complain about something, usually it is based on experience and knowledge. And if I wanted to have a desktop where JavaScript gets used everywhere I would buy a Chromebook instead.

the_why_of_y 4y ago
My reading is that performance problems are caused by interactions between reference-counted GObjects and tracing GC, nothing to do with "not having a V8 class implementation". > https://gitlab.gnome.org/GNOME/gjs/-/issues/361 https://gitlab.gnome.org/GNOME/gjs/-/issues/361 Now what can we learn here? Well, the most important lesson is that getting properties from GObjects seems to be very expensive and a major bottleneck [...] Also generally (and as expected), recursive processes like Clutters allocation machinery round tripping between C and JS land are a bad idea and should probably avoid JS land altogether > https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem... This fix is strictly specific to GObjects wrapped by GJS
- pjmlp 4y ago
  From my point of view, the whole experience end to end counts as having a V8 class implementation, and not the bare bones runtime. ChromeOS isn't only V8 without anything else.