Live data from Hacker News

Show HN: Plotting 3 years of hourly data in 150ms

leeoniya.github.io

81–90 of 118 posts

Re: Show HN: Plotting 3 years of hourly data in 150ms

#81
post #73

Let this be a lesson that JavaScript is not slow. The DOM can be slow, and downloading large bundles can be slow, and any code can be made slow if you try hard enough to write it poorly. But JavaScript the language is not slow in 2020. When we talk (or rant) about the performance of JS-based apps - running on the web or in Electron or otherwise - it's really important that the conversation focus on the factors that a…

No, JS is slow(ish). The GC pressure alone will kill you. This is fast despite being in JS by simply doing as little as possible (while still meeting the requirements on the end result, which is where the genius lies). The fastest code is no code. No code is fast even with pathologically slow languages/runtimes.

It's no slower than Python. Probably faster unless you're staying within a native library like NumPy.

But that wasn't my main point: my main point is that people love to rant about "JavaScript apps" while maintaining (willful?) ignorance about what the actual factors are that manifest as the slowness they experience. Sometimes it's poor usage of the DOM. Usually it's ads. It's almost never the unavoidable overhead of JS cycles.

Re: Show HN: Plotting 3 years of hourly data in 150ms

#84
post #52

I feel like in general people underestimate just how fast computers are. Crazy to hear about libraries that choke on a couple thousand points when compared to https://hackernoon.com/drawing-2-7-billion-points-in-10s-ecc... (for instance)

completely agree. additionally, it's hard to overstate how impressive modern javascript JITs are, as well as GPUs. every time i visit a web page that downloads 2MB of js and spins up my CPU fan, i feel ashamed that this is the industry (webdev) where i make my living. at least with uPlot i show that all this waste is not necessary.

The problem with large websites is that there's a dozen layers of abstractions leading to large and inefficient code. But when it comes to just raw speed (iterating over a huge array of numbers in a tight loop, like drawing this chart), then it's blazing fast especially with JIT. That's specifically where a lot of people underestimate JS. I've seen a lot of people do things in the backend when they can just send all the data and do all the filtering/sorting locally leading to much faster UX.

Re: Show HN: Plotting 3 years of hourly data in 150ms

#85

Beautiful demo, thank you for sharing. I work with analytic tools to watch production systems and they boil my data down to a pathetic number of datapoints prior to rendering, when you know computers — even in a browser — are vastly more capable.

I don't think systems like this have ever been really limited to the amount of data they can _present_. A bigger limiting factor is the volume of data they can ingest, at what cardinality (ideally arbitrary), and how quickly they can get it back to you, transformed in some way (e.g. "i want to see p95").

That said, things like SignalFx or Datadog are certainly slow at the presentation layer, too ;)

Re: Show HN: Plotting 3 years of hourly data in 150ms

#86
Very nice project, but I just want to randomly point out that 3 years of hourly data is really not as much, as it may sound to somebody. In fact, it's 3 times less than 24 hours of every-second of data, which is pretty common scale for all sorts of real-time monitoring tools we often use. These fine-sliced stats really pile up quickly...

Re: Show HN: Plotting 3 years of hourly data in 150ms

#87
post #86

Very nice project, but I just want to randomly point out that 3 years of hourly data is really not as much, as it may sound to somebody. In fact, it's 3 times less than 24 hours of every-second of data, which is pretty common scale for all sorts of real-time monitoring tools we often use. These fine-sliced stats really pile up quickly...

> but I just want to randomly point out that 3 years of hourly data is really not as much, as it may sound to somebody.

you're right, it isn't. and yet many js charting libs struggle even with this.

on my i5 thinkpad with integrated gpu uPlot can render 600 series x 8,000 datapoints in ~2000ms [1]. and it finishes this job in ~7s on my 2015 sony z5 compact phone. so there's that :)

but really, pumping 4.8M datapoints into a browser is probably not a great idea. you're gonna want to aggregate on the server at some point. just sayin'.

[1] https://leeoniya.github.io/uPlot/bench/uPlot-600-series.html

Re: Show HN: Plotting 3 years of hourly data in 150ms

#88
post #81

Earlier quoted context omitted.

No, JS is slow(ish). The GC pressure alone will kill you. This is fast despite being in JS by simply doing as little as possible (while still meeting the requirements on the end result, which is where the genius lies). The fastest code is no code. No code is fast even with pathologically slow languages/runtimes.

It's no slower than Python. Probably faster unless you're staying within a native library like NumPy. But that wasn't my main point: my main point is that people love to rant about "JavaScript apps" while maintaining (willful?) ignorance about what the actual factors are that manifest as the slowness they experience. Sometimes it's poor usage of the DOM. Usually it's ads. It's almost never the unavoidable overhead of…

Javascript is probably at least an order of magnitude faster than Python.

Re: Show HN: Plotting 3 years of hourly data in 150ms

#89

Would it be possible to allow for the cursor to still update when doing a horizontal scroll? When I move the mouse left and right it does that, but it doesn't move when I traverse the page by horizontally scrolling Either way, just a bit of feedback on a beautiful page

can you open an issue with a repro?
Post reply on HN