4 ms·

Honestly, I don't see why any of these things require such terrible performance characteristics.

kilburn 5y ago
I tried to use examples where some inherent performance penalties where easy to see: - Unicode text: All text consumes more memory (because the character space is much larger). Basic text processing ("wrap this paragraph at 80 characters") becomes much harder, not just because bytes != glyphs, but also because glyphs can combine. - Security improvements: we now have various sandboxing, isolation, execution-protection, etc.. features in OSes. The performance impact of some of those is negligible thanks to new hardware features to help with them, but others still have a significant cost. Furthermore, some performance tricks used in old systems would simply violate the current security models and are hence impossible to do anymore. - Driver isolation: this is similar to the above. The OS is now doing more work to ensure drivers behave, the isolation forbids some more performant pathways, etc. - Wifi with some reliability: this was an example of progress being achieved. Wifi protocols are a nightmare, and I'm still amazed that they work at all. - Better trackpads: another progress example. The big issue here has been the development of smarter algorithms (and the hardware refinement to back them up). This is something that seems simple, but it took a very long time to get this anywhere acceptable (even after Apple showed the world it was possible). I can only assume that it is actually a pretty hard problem underneath. - Files that don't get corrupted: we have needed years and years of iterative improvements to finally get here, both at the FS level and on the programs above (think DBs). We are now going through journal logs, memory barries, checksumming and verifying data, using copy-on-write for FSs, etc.. All these things have non-negligible runtime and camplexity costs. In general, we have been prioritizing to make more stuff and/or making the stuff more correct, disregarding the performance aspect so long as it remains good enough (from the POV of the developers).
- dmitriid 5y ago
  > Security improvements: we now have Everyone agrees that M1 is a very fast chip, much faster than the current Intel chips shipping with Macbooks. And yet: when I trigger the native "Open File" dialog from IDEA, it still takes MacOS up to a second to verify permissions on a list of directories and mark them as available. So, given that: - M1 is blazingly fast - modern SSDs pump GBs of data per second - RAM on M1 is almost literally a part of the CPU, and the bandwidth of modern RAM is also GBs per second why does it take up to a second to verify permissions on a list of five directories? > Unicode ... Wifi ... Trackpads ... None of these require GBs of RAM and 16-core processors to barely run.

I tried to use examples where some inherent performance penalties where easy to see: - Unicode text: All text consumes more memory (because the character space is much larger). Basic text processing ("wrap this paragraph at 80 characters") becomes much harder, not just because bytes != glyphs, but also because glyphs can combine. - Security improvements: we now have various sandboxing, isolation, execution-protection, etc.. features in OSes. The performance impact of some of those is negligible thanks to new hardware features to help with them, but others still have a significant cost. Furthermore, some performance tricks used in old systems would simply violate the current security models and are hence impossible to do anymore. - Driver isolation: this is similar to the above. The OS is now doing more work to ensure drivers behave, the isolation forbids some more performant pathways, etc. - Wifi with some reliability: this was an example of progress being achieved. Wifi protocols are a nightmare, and I'm still amazed that they work at all. - Better trackpads: another progress example. The big issue here has been the development of smarter algorithms (and the hardware refinement to back them up). This is something that seems simple, but it took a very long time to get this anywhere acceptable (even after Apple showed the world it was possible). I can only assume that it is actually a pretty hard problem underneath. - Files that don't get corrupted: we have needed years and years of iterative improvements to finally get here, both at the FS level and on the programs above (think DBs). We are now going through journal logs, memory barries, checksumming and verifying data, using copy-on-write for FSs, etc.. All these things have non-negligible runtime and camplexity costs. In general, we have been prioritizing to make more stuff and/or making the stuff more correct, disregarding the performance aspect so long as it remains good enough (from the POV of the developers).

dmitriid 5y ago
> Security improvements: we now have Everyone agrees that M1 is a very fast chip, much faster than the current Intel chips shipping with Macbooks. And yet: when I trigger the native "Open File" dialog from IDEA, it still takes MacOS up to a second to verify permissions on a list of directories and mark them as available. So, given that: - M1 is blazingly fast - modern SSDs pump GBs of data per second - RAM on M1 is almost literally a part of the CPU, and the bandwidth of modern RAM is also GBs per second why does it take up to a second to verify permissions on a list of five directories? > Unicode ... Wifi ... Trackpads ... None of these require GBs of RAM and 16-core processors to barely run.