309
Software is slow because of bad design, not slow languages (www.seangoedecke.com)
submitted 1 day ago by to c/programming@programming.dev
108 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 4 points 1 day ago* (last edited 1 day ago) (8 children)

Why would that slow it down exactly? Nothing really slow about GPU accelerated graphics these days?

Would love to hear the technical reasons. You need to have UI kits for GUIs. Responsive and accessible UI kits are hard. The web solved them a decade ago and made them easier to achieve than ever before. Why invent the wheel twice?

I/O is the slowest thing ever. The more I/O dependent your app is, the slower it will be. It is not easy to make a slow web UI with zero I/O. Very easy to make a slow UI with a native toolkit and high I/O usage. Network calls are I/O. Analytics are I/O. Most enterprise apps these days demand so much analytics they effectively have spyware on their own users to optimize and A/B test against.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 5 points 21 hours ago (1 child)

    It's mostly because of memory cache misses. JS creates a ton of closures and has a lot of context switching. JS engines are basically a modern day miracle for how fast they are but somehow webapps are still sluggish.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 6 points 1 day ago (5 children)

    It still adds a lot of layers between the user and the processor.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 4 points 22 hours ago (3 children)

    What does that even mean? I make GUIs in web technologies, I make GUIs in godot, I make GUIs in bevy, I make GUIs in flutter, etc etc. Blink uses Skia. Flutter uses Skia. Is skia just bad? What are you even saying? What is slow about web tech, really? To me performance is almost always bad engineering choices like not understanding or handling I/O.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 3 points 20 hours ago (2 children)

    To me performance is almost always bad engineering choices like not understanding or handling I/O.

    So that means every single developer that has ever used Electron or CEF for something, has been making bad engineering choices?

    You may have something there.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 18 hours ago (1 child)

    Why is how nodejs or cef does I/O worse than any other GUI toolkit's I/O layer?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 17 hours ago*

    I haven't gotten deep enough into it to see what's wrong, but pretty much any Electron or CEF application I've used has been pretty slow, though it could be that I have a very weak PC since I only have a Ryzen 5700 and 32 gigs of DDR4 and my NVMe drives (root and home partitions being separate physical drives) are only running on PCIe 3.0, not 4.0 or 5.0. Perhaps I ought to see if things like Steam or Discord run better if I upgrade to a mid-range PC with a Ryzen 9900x, faster RAM and faster drives, but I'm not made of money.

    Games run smoothly, mind you - those don't require very beefy hardware after all. It's only extremely visually and IO demanding applications like Steam or Discord that run like absolute dogshit for me. Slack used to be pretty bad too, but I don't use it these days, don't need it. Ditto for Mattermost. I have one computer dedicated to Microsoft Teams, it's got a 12th gen i7 in it which can't really handle the task, but that's just Microsoft for you, everything they've made in the last decade has been shit.

  • permalink
  • fedilink
  • source
  • parent