WingNews logo WingNews
top | item 26471389

(no title)

gbrayut | 5 years ago

Reminds me of a Windows installer I working on many years ago, that seemed to take a long time using CPU but otherwise not doing any real work. Turned out the SDK we were using tried to update the progress bar every kilobyte or something like that, and our near-gigabyte sized packages filled the message loop with a bunch of pointless updates (30.001% -> 30.002% but both displayed as 30%).

Once the vendor fixed the issue it shaved a few minutes off the install time that had previously just been a UI glitch (processing the large backlog of progress bar update messages).

discuss

order

strogonoff|5 years ago

> Turned out the SDK we were using tried to update the progress bar every kilobyte or something like that, and our near-gigabyte sized packages filled the message loop with a bunch of pointless updates (30.001% -> 30.002% but both displayed as 30%).

Had a similar situation with an Electron app I worked on. App’s window was getting very stuttery at some point during a long-running operation done by a third-party library, even though it happened in a background worker thread and wasn’t supposed to block the UI (which simply showed the progress of the operation).

Turned out, that third-party library called my progress notifier function (in which I used Electron’s IPC to notify the GUI) on increments that were fairly spaced out most of the time, but really frequent during some operations. Mere overhead from IPC calls and GUI updates added up to a point where everything lagged, even though the operation itself wasn’t that intensive. I wrapped my progress notifier in a throttler, which I frankly should’ve done much earlier, and that solved it.

easton|5 years ago

This must be why when you turn off the progress bar for Invoke-WebResource in PowerShell your download speeds become reasonable, as otherwise it updates the terminal every byte and takes a million years to download stuff that takes a second in Firefox or via wget.