3 ms·

A standard version, when used the same way as everyone else, has already been tested. You might run into bugs, but I don't see as many as with new things. Per

A standard version, when used the same way as everyone else, has already been tested. You might run into bugs, but I don't see as many as with new things. Performance often doesn't matter that much, because your program often only spends a trivial amount of CPU doing something. I don't really care about a few microseconds to determine a file type given a name, when there's 10x longer to decompress the file and 100x longer to even load the dialog to find it. For the things that the program actually does spend a lot of time on, there's usually a way to optimize it with hardware instructions, GPU stuff, special case algorithmic shortcuts, etc, which are hard and tedious to do for multiple platforms. The ultracomplex solution might be just as fast. Plus, DIY stuff is rarely general enough to be reusable. The standard solution might be hard to set up, but it will probably be less work that writing something from scratch. And it will almost certainly be less work for a maintainer to understand. They probably won't have to learn anything at all, they've seen all the patterns before on every project. DIY is great if you value simplicity just for it's own sake, otherwise I'm not sure I see the appeal. A lot of programmers seem to get into programming specifically because they value simplicity, they like to understand and work with new ideas and complexity gets in the way of understanding, so I see why they might like to about reuse.

Pannoniae 3y ago
"Performance often doesn't matter that much, because your program often only spends a trivial amount of CPU doing something. I don't really care about a few microseconds to determine a file type given a name, when there's 10x longer to decompress the file and 100x longer to even load the dialog to find it." I agree with the rest but this is how we are at a point where we have to wait for windows to open. Unlike on Windows NT. It's not a problem of one thing being slow - if everything is being slightly slow, it's a death by thousand cuts.
- eternityforest 3y ago
  I think most of the problem with waiting for windows to open is a matter of lack of caching, or waiting on some process that could have been parallel, or something like that. Rarely do I ever see a library that takes more than milliseconds to import, or something slowed down on a function only called on a click or every few minutes or otherwise not in an inner loop. I see lots of slow file open dialogs, which I'm told is often because of checking for network drives and things like that. I've seen exactly one library that was causing me so much performance trouble I had to ditch it, and that was an rrules engine. Finding the next occurrence of something like "Every five minutes on Thursday" was taking an insane amount of time, but that's because I was calling it constantly to schedule lots of different things that happened very frequently. I've also seen lots of things be slow because they wait for the network too. But basic stuff that libraries are normally used for generally seem to be fine. I don't think there's any way I could write a faster gaussian blur than Pillow or a faster text search than the default regex libs.
  - Pannoniae 3y ago
    Most applications take seconds to open - and that's with fairly high-end hardware and an NVMe drive. The worst offenders are the "webpages packaged as programs" (electron, CEF) and UWP. I don't think the lack of caching is the problem - the real problem is doing so much work to open the application which requires caching.

Pannoniae 3y ago

"Performance often doesn't matter that much, because your program often only spends a trivial amount of CPU doing something. I don't really care about a few microseconds to determine a file type given a name, when there's 10x longer to decompress the file and 100x longer to even load the dialog to find it." I agree with the rest but this is how we are at a point where we have to wait for windows to open. Unlike on Windows NT. It's not a problem of one thing being slow - if everything is being slightly slow, it's a death by thousand cuts.

eternityforest 3y ago
I think most of the problem with waiting for windows to open is a matter of lack of caching, or waiting on some process that could have been parallel, or something like that. Rarely do I ever see a library that takes more than milliseconds to import, or something slowed down on a function only called on a click or every few minutes or otherwise not in an inner loop. I see lots of slow file open dialogs, which I'm told is often because of checking for network drives and things like that. I've seen exactly one library that was causing me so much performance trouble I had to ditch it, and that was an rrules engine. Finding the next occurrence of something like "Every five minutes on Thursday" was taking an insane amount of time, but that's because I was calling it constantly to schedule lots of different things that happened very frequently. I've also seen lots of things be slow because they wait for the network too. But basic stuff that libraries are normally used for generally seem to be fine. I don't think there's any way I could write a faster gaussian blur than Pillow or a faster text search than the default regex libs.
- Pannoniae 3y ago
  Most applications take seconds to open - and that's with fairly high-end hardware and an NVMe drive. The worst offenders are the "webpages packaged as programs" (electron, CEF) and UWP. I don't think the lack of caching is the problem - the real problem is doing so much work to open the application which requires caching.