Living in the distant future, we have remarkable technology. More Memory, Storage, and Processing power than we could ever need, want, or imagine. We even have the graphics chips integrated directly onto the CPU with specs unfathomable 25 years ago.
And despite all this, the software has gotten slower. There are delays when clicking/opening different windows, panels, and interfaces.
I've had junk computers running Windows 98 and XP that ran snappier than modern systems. What a joke.
I wouldn't quite say there is a move to interpreted languages because interpreted languages have evolved into just in time compiled languages. About 100 times faster than interpreted langues and 5x slower than pre-compiled languages. About 10x slower than fully optimized pre-compiled languages.
But the framework on framework issue is on point.
But even with these JIT languages being 5x slower than pre-compiled this is not where slowdowns come from. The code itself runs fast. It's memory management. The frameworks on frameworks means you have a lot of allocations and deallocations on heap memory per function call made at the highest layer.
What lower level languages like C did wasn't just run the code faster, but because you could pass pointers around you could allocate memory at the highest level and pass the memory down into function calls so they don't need to allocate to do their processing. Then you can recycle memory. Allocate once is mandatory for anything that needs to run really fast. You wouldn't do that everywhere in your C code but it wasn't hard to figure out what needed to run fast and then do that. With framework on framework JS or C# even if you knew what needed to be faster you don't have such a straightforward pattern to make a slice of code run fast.
Basically these slow downs are caused by memory thrashing and IPC race conditions. The second one is what afflicts windows. So in linux realm you are just dealing with the memory bloat of multiple layers of frameworks, which while not being 100% snappy is still not horrible. This is why linux is never horribly slow even when using a bloated software but windows can be absolutely horrible just trying to open or close a window. You end up with indefinite hangs for things that should take zero processing.
Thedancingsousa 1 points 3 days ago
I wouldn't quite say there is a move to interpreted languages because interpreted languages have evolved into just in time compiled languages. About 100 times faster than interpreted langues and 5x slower than pre-compiled languages. About 10x slower than fully optimized pre-compiled languages.
But the framework on framework issue is on point.
But even with these JIT languages being 5x slower than pre-compiled this is not where slowdowns come from. The code itself runs fast. It's memory management. The frameworks on frameworks means you have a lot of allocations and deallocations on heap memory per function call made at the highest layer.
What lower level languages like C did wasn't just run the code faster, but because you could pass pointers around you could allocate memory at the highest level and pass the memory down into function calls so they don't need to allocate to do their processing. Then you can recycle memory. Allocate once is mandatory for anything that needs to run really fast. You wouldn't do that everywhere in your C code but it wasn't hard to figure out what needed to run fast and then do that. With framework on framework JS or C# even if you knew what needed to be faster you don't have such a straightforward pattern to make a slice of code run fast.
Basically these slow downs are caused by memory thrashing and IPC race conditions. The second one is what afflicts windows. So in linux realm you are just dealing with the memory bloat of multiple layers of frameworks, which while not being 100% snappy is still not horrible. This is why linux is never horribly slow even when using a bloated software but windows can be absolutely horrible just trying to open or close a window. You end up with indefinite hangs for things that should take zero processing.