51–60 of 125 posts
Earlier quoted context omitted.
quiet reminder that writing to file descriptors is blocking. STDERR and STDOUT are file descriptors.
Maybe so, but, as pointed out elsewhere in the thread, printing to stdout is much, much, much, much slower than printing to a file. The fact that stdout is a file descriptor can only explain a vanishingly small quantity of the time cost of using it.
Earlier quoted context omitted.
That's highly unlikely. Archive Utility is just slow.
What is highly unlikely about that? That seems more plausible than, zlib is magically 1000x slower when used by Archive Utility.
I wonder whether this is not an example of a UI interaction which is slow on purpose, to emphasize how much work the OS is doing for you. TaxAct and TurboTax, for example, both operate on (in the typical case) kilobyte scale data requiring trivial math. They also make both saving the data and calculating taxes take 5+ wall-clock seconds when they actually require milliseconds and nanoseconds respectively. This is lar…
https://blogs.msdn.microsoft.com/oldnewthing/20060220-00/?p=...
A Windows program ran faster if you clicked and held the mouse button on the title bar (as if you were going to move the window) because it would stop the window from re-drawing itself, making whatever loop it was running (and constantly updating the GUI) go faster.
I wonder whether this is not an example of a UI interaction which is slow on purpose, to emphasize how much work the OS is doing for you. TaxAct and TurboTax, for example, both operate on (in the typical case) kilobyte scale data requiring trivial math. They also make both saving the data and calculating taxes take 5+ wall-clock seconds when they actually require milliseconds and nanoseconds respectively. This is lar…
I wonder whether this is not an example of a UI interaction which is slow on purpose, to emphasize how much work the OS is doing for you. TaxAct and TurboTax, for example, both operate on (in the typical case) kilobyte scale data requiring trivial math. They also make both saving the data and calculating taxes take 5+ wall-clock seconds when they actually require milliseconds and nanoseconds respectively. This is lar…
I've encountered this in command-line programs as well. Print statements take a non-zero amount of time and depending on the language, can be quite slow, so for an otherwise-fast operation in a loop, if it prints a line every time then it can contribute significantly to the overall speed of the program. Removing the print statements in some cases can speed up the code by an order of magnitude.
Earlier quoted context omitted.
quiet reminder that writing to file descriptors is blocking. STDERR and STDOUT are file descriptors.
Maybe so, but, as pointed out elsewhere in the thread, printing to stdout is much, much, much, much slower than printing to a file. The fact that stdout is a file descriptor can only explain a vanishingly small quantity of the time cost of using it.
I wonder whether this is not an example of a UI interaction which is slow on purpose, to emphasize how much work the OS is doing for you. TaxAct and TurboTax, for example, both operate on (in the typical case) kilobyte scale data requiring trivial math. They also make both saving the data and calculating taxes take 5+ wall-clock seconds when they actually require milliseconds and nanoseconds respectively. This is lar…
It sounds like he and his team came up with the idea in that instance.