Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

leeoniya.github.io

Post reply on HN
Print view View original

71–80 of 118 posts

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

#71

Post by leeoniya »

fabian2k wrote: post #51
43920 wrote: post #46

Earlier quoted context omitted.

It looks like the mouse lines and the selection highlight are just partially-transparent divs stacked on top of the canvas that get moved around, so nothing actually gets redrawn unless the date range changes (which is a pretty clever approach!).

That's something I expected, you really don't want to trigger redraws on mouse over. What surprised me was that I couldn't tell the the times where I zoomed in or out from the JS flame chart. Usually that is really obvious, but in this case zooming was so fast that you could hardly see it. And this graph has probably around ~194k data points (388k in the source data, I assume that's x and y). I'm not entirely sure ab…

> And this graph has probably around ~194k data points

no, the top graph is pretty much what the title says: 3 * 365 * 24.

but 194k is also no problem :)

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

#73

Post by _bxg1 »

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 actually matter.

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

#74

Post by _bxg1 »

zlepper wrote: post #13

This looks really really neat! Just want to ask, because I love talking about render performance: have you tried doing this using offfscreen canvas? That should allow you to move a lot of things to a worker, so you avoid blocking the rendering with js? It probably won’t speed up the total time to finished render, but I assume it will lock the page for a shorter period of time?

If the rendering is this controlled (and sparse), blocking the thread with it isn't really a concern. And with this data size, serialization/deserialization between the main and worker thread would probably become nontrivial.

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

#76

Post by gesman »

jparmer wrote: post #17
doublesCs wrote: post #12

Earlier quoted context omitted.

Hi, I'm very interested in this. I've been using dask/plotly for a side project but it's just too slow. If you know dask, do you think you could discuss which features of dask your project has and doesn't have?

Here's a Dash app that use Dask & Datashader for fast aggregations on +40M rows: https://dash-gallery.plotly.host/dash-world-cell-towers The source code, which can be used as a Dash + Dask boilerplate, is here: https://github.com/plotly/dash-world-cell-towers Feel free to ask questions at community.plot.ly

It plots cell towers in the middle of my residential neighborhood where i absolutely sure there aren't any

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

#77

Post by leeoniya »

gesman wrote: post #76
jparmer wrote: post #17

Earlier quoted context omitted.

Here's a Dash app that use Dask & Datashader for fast aggregations on +40M rows: https://dash-gallery.plotly.host/dash-world-cell-towers The source code, which can be used as a Dash + Dask boilerplate, is here: https://github.com/plotly/dash-world-cell-towers Feel free to ask questions at community.plot.ly

It plots cell towers in the middle of my residential neighborhood where i absolutely sure there aren't any

maybe they're Stingrays ;)

https://en.m.wikipedia.org/wiki/Stingray_phone_tracker

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

#79

Post by ComputerGuru »

_bxg1 wrote: 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.

Post reply on HN