3 ms·

Using a perpetual timer to poll anything is a waste of your users’ battery life. Even if the actual computation you’re doing seems insignificant, the repeated w

Using a perpetual timer to poll anything is a waste of your users’ battery life. Even if the actual computation you’re doing seems insignificant, the repeated wakeups prevent the processor from reaching deeper sleep states. https://wiki.ubuntu.com/Kernel/PowerManagement/IdentifyingIssues#Wakeups https://wiki.ubuntu.com/Kernel/PowerManagement/IdentifyingIs...

tinus_hn 4y ago
I would hope most sensible browsers would simply stop any polling timers after a short while when the user is not interacting with the page. Every website ‘needs’ to run stuff like that, there is no alternative to just reigning them in.
eyelidlessness 4y ago
While a perfectly reasonable point, and one which might benefit other readers, I think it’s worth adding that the article seems fairly clear that it’s demonstrating a proof of concept that can be built upon. I certainly didn’t take it to suggest that I should go write a convoluted setInterval to implement GC in WASM. Amusingly (to me), I’ve been working on a variety of performance-focused efforts—professionally on directly deliverable tasks, professionally on exploratory spikes for more holistic future improvements, and in pet personal projects. I find myself deliberately writing throwaway code that’s just as painfully suboptimal quite a lot. At worst it helps me quickly iterate on the actual bottleneck without focusing on the things I’m not trying to optimize. It can be more helpful than that though, when it reveals sometimes unexpected JIT perf characteristics. Sometimes it reveals that a hot loop optimization isn’t going to bear much fruit because the JIT is going to optimize the baseline code better than anything I have in mind. Other times it reveals cases where I see dramatic benefits from an initial JIT pass that vanish because other factors cause a deoptimization. Granted I think it’s still good to slap a big warning like this on obviously suboptimal code! But I also think people working on performance sensitive code in a dynamic JIT/GC environment should be encouraged to write weird suboptimal throwaway glue code around their perf focal point. You can learn a lot if you’re profiling!
- siwatanejo 4y ago
  One thing is lack of performance profiling, another thing is a design flaw (can this performance issue be really tackled or is it a limitation derived from the platform?). Which one are we looking at?
  - eyelidlessness 4y ago
    We’re looking at neither. I even double checked the article and it’s very explicitly an example demonstrating very clearly a concept. It’s a proof of concept. It’s not a design so it won’t suffer from a flaw, it’s not expected to be profiled because it’s not a solution. My comment was an aside that such code lacking design can aid profiling other code. Intentionally writing poorly performing code has benefits in understanding other performance details in some scenarios. You didn’t seem to address this either, just reiterated a grievance with the article. I expect this is going to be a typical HN topic where strong opinions fly by, but I sincerely wonder if you might also benefit from slowing down and reading more closely?
    - krona 4y ago
      A proof of concept 'is a realization of a certain method or idea in order to demonstrate its feasibility'. The article presents an 'inventive step' (https://en.wikipedia.org/wiki/Inventive_step_and_non-obviousness https://en.wikipedia.org/wiki/Inventive_step_and_non-obvious...) in the form of a POC which nobody should use, and so I don't know what it accomplishes, really. +1 for C++ though.

tinus_hn 4y ago

I would hope most sensible browsers would simply stop any polling timers after a short while when the user is not interacting with the page. Every website ‘needs’ to run stuff like that, there is no alternative to just reigning them in.

eyelidlessness 4y ago

While a perfectly reasonable point, and one which might benefit other readers, I think it’s worth adding that the article seems fairly clear that it’s demonstrating a proof of concept that can be built upon. I certainly didn’t take it to suggest that I should go write a convoluted setInterval to implement GC in WASM. Amusingly (to me), I’ve been working on a variety of performance-focused efforts—professionally on directly deliverable tasks, professionally on exploratory spikes for more holistic future improvements, and in pet personal projects. I find myself deliberately writing throwaway code that’s just as painfully suboptimal quite a lot. At worst it helps me quickly iterate on the actual bottleneck without focusing on the things I’m not trying to optimize. It can be more helpful than that though, when it reveals sometimes unexpected JIT perf characteristics. Sometimes it reveals that a hot loop optimization isn’t going to bear much fruit because the JIT is going to optimize the baseline code better than anything I have in mind. Other times it reveals cases where I see dramatic benefits from an initial JIT pass that vanish because other factors cause a deoptimization. Granted I think it’s still good to slap a big warning like this on obviously suboptimal code! But I also think people working on performance sensitive code in a dynamic JIT/GC environment should be encouraged to write weird suboptimal throwaway glue code around their perf focal point. You can learn a lot if you’re profiling!

siwatanejo 4y ago
One thing is lack of performance profiling, another thing is a design flaw (can this performance issue be really tackled or is it a limitation derived from the platform?). Which one are we looking at?
- eyelidlessness 4y ago
  We’re looking at neither. I even double checked the article and it’s very explicitly an example demonstrating very clearly a concept. It’s a proof of concept. It’s not a design so it won’t suffer from a flaw, it’s not expected to be profiled because it’s not a solution. My comment was an aside that such code lacking design can aid profiling other code. Intentionally writing poorly performing code has benefits in understanding other performance details in some scenarios. You didn’t seem to address this either, just reiterated a grievance with the article. I expect this is going to be a typical HN topic where strong opinions fly by, but I sincerely wonder if you might also benefit from slowing down and reading more closely?
  - krona 4y ago
    A proof of concept 'is a realization of a certain method or idea in order to demonstrate its feasibility'. The article presents an 'inventive step' (https://en.wikipedia.org/wiki/Inventive_step_and_non-obviousness https://en.wikipedia.org/wiki/Inventive_step_and_non-obvious...) in the form of a POC which nobody should use, and so I don't know what it accomplishes, really. +1 for C++ though.