4 ms·

A really nice thing about code written from the 90s and earlier is that it was designed from the get go to be perfomant, because it had to be. No one in convent

A really nice thing about code written from the 90s and earlier is that it was designed from the get go to be perfomant, because it had to be. No one in conventional sw writes code like that anymore, not really. eg. When was the last time you used a profiler? I recently updated from Fedora 24 to 25. I noticed a big performance drop until I shoved more ram into my desktop, and now it's fine again. I can't be certain but I'd wager that this might be because F25 is the first Fedora to use Wayland (over X) by default. X might be old and fugly but it was certainly written in an era where it had to achieve a certain baseline level of performance.

LeanderK 10y ago
to be fair, wayland improves upon X in many other areas other than performance and while this might be true for the machine/workloads i did not notice any slowdown running it in a vm (i also don't use that much ram, while an editor/ide might be hungry they only eat a few gigabytes. I rarely run things that really eat ram for lunch).
trishume 10y ago
It's true that Wayland uses more RAM and if you don't have enough swapping will kill you. But in this case (and others) RAM use is inversely correlated with performance. For example Wayland uses more RAM as full backing buffers for every window, and this actually makes moving windows around faster because it doesn't have to ask the app to re-draw exposed areas. Unless you spill into swap, then you are indeed screwed.
- floatboth 10y ago
  Xorg with a compositor does the exact same thing with full backing buffers for every window. The only way X is using less RAM is if you run without compositing. If you're not using a compositor, you must be either living in the 90s or using a device without a supported GPU. Compositing is not new, people were excited about Compiz desktop cubes and wobbly windows back in the mid-2000s! A Wayland compositor running directly on EGL should always be faster than Xorg with a compositor. Xorg acts as an awkward middleman between your app and the compositor, wasting time on buffer copies.
sunnyhacker 10y ago
I use Xcode profiler on completed new features every time before I submit a pull request. If you do iOS/OSX development, it is always a good idea to use Xcode profiler to catch memory leaks/abandoned memory in order to minimize app crashes. Abandoned Memory: https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/FindingAbandonedMemory.html#//apple_ref/doc/uid/TP40004652-CH80-SW1 https://developer.apple.com/library/content/documentation/De... Memory leaks: https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/FindingLeakedMemory.html#//apple_ref/doc/uid/TP40004652-CH81-SW1 https://developer.apple.com/library/content/documentation/De...
ruslan_talpa 10y ago
Maybe this logic works as a generalisation but not in case of PG, the real push for the speed of PG came much later, like after the version 7
anarazel 10y ago
> A really nice thing about code written from the 90s and earlier is that it was designed from the get go to be perfomant, because it had to be. I don't think that's really the case in PG. Sure there's some places like that, but there were a lot of fairly fundamental performance issues only fixed in the last year. And there's still a lot of things to be done. Additionally a lot things that you had to do 20+ years ago, aren't the ones that you have to do today to get good performance. Being careful about cache usage and pipeline stalls became a lot more important on recent-ish CPUs than earlier ones. > No one in conventional sw writes code like that anymore, not really. eg. When was the last time you used a profiler? I think that's more a difference between application and infrastructure pieces of code. It's only worth spending time (and have skilled enough people) doing detailed optimization work if $project is going to be in the bottleneck for a lot of people. A couple of days on postgres can result in a lot bigger savings, if you multiply the saved optimization time over all its users.

LeanderK 10y ago

to be fair, wayland improves upon X in many other areas other than performance and while this might be true for the machine/workloads i did not notice any slowdown running it in a vm (i also don't use that much ram, while an editor/ide might be hungry they only eat a few gigabytes. I rarely run things that really eat ram for lunch).

trishume 10y ago

It's true that Wayland uses more RAM and if you don't have enough swapping will kill you. But in this case (and others) RAM use is inversely correlated with performance. For example Wayland uses more RAM as full backing buffers for every window, and this actually makes moving windows around faster because it doesn't have to ask the app to re-draw exposed areas. Unless you spill into swap, then you are indeed screwed.

floatboth 10y ago
Xorg with a compositor does the exact same thing with full backing buffers for every window. The only way X is using less RAM is if you run without compositing. If you're not using a compositor, you must be either living in the 90s or using a device without a supported GPU. Compositing is not new, people were excited about Compiz desktop cubes and wobbly windows back in the mid-2000s! A Wayland compositor running directly on EGL should always be faster than Xorg with a compositor. Xorg acts as an awkward middleman between your app and the compositor, wasting time on buffer copies.

sunnyhacker 10y ago

I use Xcode profiler on completed new features every time before I submit a pull request. If you do iOS/OSX development, it is always a good idea to use Xcode profiler to catch memory leaks/abandoned memory in order to minimize app crashes. Abandoned Memory: https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/FindingAbandonedMemory.html#//apple_ref/doc/uid/TP40004652-CH80-SW1 https://developer.apple.com/library/content/documentation/De... Memory leaks: https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/FindingLeakedMemory.html#//apple_ref/doc/uid/TP40004652-CH81-SW1 https://developer.apple.com/library/content/documentation/De...

ruslan_talpa 10y ago

Maybe this logic works as a generalisation but not in case of PG, the real push for the speed of PG came much later, like after the version 7

anarazel 10y ago

> A really nice thing about code written from the 90s and earlier is that it was designed from the get go to be perfomant, because it had to be. I don't think that's really the case in PG. Sure there's some places like that, but there were a lot of fairly fundamental performance issues only fixed in the last year. And there's still a lot of things to be done. Additionally a lot things that you had to do 20+ years ago, aren't the ones that you have to do today to get good performance. Being careful about cache usage and pipeline stalls became a lot more important on recent-ish CPUs than earlier ones. > No one in conventional sw writes code like that anymore, not really. eg. When was the last time you used a profiler? I think that's more a difference between application and infrastructure pieces of code. It's only worth spending time (and have skilled enough people) doing detailed optimization work if $project is going to be in the bottleneck for a lot of people. A couple of days on postgres can result in a lot bigger savings, if you multiply the saved optimization time over all its users.