← Back to context

Comment by pjmlp

4 years 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/361

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.

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

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...

This fix is strictly specific to GObjects wrapped by GJS

  • 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.