The fact that we are celebrating that a chat app only uses 300MB ram at launch instead of 1GB seems absolutely ludicrous to me

The early versions of Skype used about 30MB RAM while in a video call and by the early 2000s standards it was bloatware. Before that we used WebEx in the 90s which was a browser ActiveX or Java applet and RAM use was about 6MB in a video call. In the early / mid 90s I used CU-SeeMe for video calls and its RAM footprint was just over 2MB on Mac System 7

Something has clearly gone very wrong in the software development process in the last 2-3 decades and while Im encouraged to see that some people are interested in reversing that trend I still find the resource wastage has me shaking my head sometimes

▲ mike_hearn 2 hours ago | parent [-]

A lot of that RAM is just high resolution bitmaps. You can have apps that fit in 10MB of RAM today if you're comfortable with the UI quality of an app circa 2000 (e.g. icons are 16x16 pixels at 8 bit colour depth).

▲ BadlyDrawnBoy 2 hours ago | parent [-]

Usually thats not the case. Its mostly abstraction layers upon abstraction layers upon abstraction layers that causes this issue

Sometime in the late 90s there started a fundamental change in the software development process. We changed from optimising software for the end user (development is difficult) to optimising the software development process for the developer at the expense of user resources

▲ mike_hearn 2 hours ago | parent [-]

That's true for Electron apps. For other kinds of desktop app, it's mostly stuff like artwork, double buffers and fonts. Go profile a desktop app heap and see for yourself.

One of the main selling points of Turbo Pascal was OWL: the Object Windows Library, which was just a big OOP abstraction over Win16. Here's some sample code:

https://github.com/TeamVault/pascal-programs/blob/master/Pas...

Doesn't look radically different to how a GUI app that targets a native framework would look today. OWL added bloat to make developer lives easier. It was ever thus.

▲ BadlyDrawnBoy an hour ago | parent [-]

I think its true for most types of modern development for apps with a UI, not just electron

>Doesn't look radically different to how a GUI app that targets a native framework would look today

Modern "Native" frameworks are part of the problem. I cant comment on Windows current state as I havent used Windows since I moved my gaming rig from Windows 7 to Linux many, many years ago but even then Windows frameworks were a complete mess

Take Libadwaita for example. I migrated an old, very simple disk image manipulation utility app last year from GTK2 to modern gnome. No change in capabilities, a simple clone in GTK4 / Libadwaita. It went from using ~19MB to ~185MB without any additional functionality simply by switching the "Native" framework

▲ kvemkon an hour ago | parent | next [-]

> GTK4

After my comment https://news.ycombinator.com/item?id=49235430 I've investigated the high RAM jump issue a bit further. It turned out, 60 MB comes from MESA / video graphics driver, right after the first function call, that triggers OpenGL/... context initialization. Thus:

  GTK2 14 MB
  GTK3 24 MB
  GTK4 38 MB  (+ 60 MB video acceleration)

Looks a bit better. But we still need 98 MB total.

▲ mike_hearn an hour ago | parent | prev [-]

Try GSK_RENDERER=cairo and see if it helps. I think the memory usage increase will mostly be GPU buffers. If GPU rendering isn't necessary for your app then it's pure bloat to use it, indeed. But with very large hi res screens it's often the case now that CPU rendering can't keep up anymore.

	▲	kvemkon 44 minutes ago \| parent [-]
		3 MB RSS less with GTK4 4.22.4 on Debian Forky (testing).