At yesterday's meetup I demoed a node and wire too...
# share-your-work
j
At yesterday's meetup I demoed a node and wire tool I'm working on in the scientific computing domain. @Márton Gunyhó had an interesting question, so I'm sharing here in case anyone has any related thoughts:
do you use some graph algorithm to figure out what needs to be recomputed, or do you keep all intermediate values in the wires in memory? I imagine the latter would get pretty heavy pretty fast.
Currently I've gone with the simple/naive approach of just keeping everything in memory. This is nice because any long-running nodes at the top of the network don't need to recompute when their descendants need to re-run. This does mean that you can run out of memory quickly if you are dealing with large pieces of data though. I'm not sure what my long-term solution is yet. Currently my thoughts are to start dropping/caching-to-disk large pieces of data as memory usage to get too high, and recompute when they are needed again. In the meantime, it's not too bad for the primary use cases I have in mind to simply be content with working with a subset of data that fits into memory.
Also, thank you @Márton Gunyhó for letting me know about https://xarray.dev/! I wish I knew about this library sooner
k
The future optimization for using less memory reminds me of memoryless textures and sparse textures in GPU coding land. If you don’t need intermediate steps, you can just reuse the memory.
k
Something you might consider is having the user select what to keep in memory. Provide a simple and unobtrusive UI (e.g. a small button), and some equally unobtrusive UI for figuring out the size of the dataset (e.g. hovering over that button). Background: as a power user, I much prefer manual control over some superficially smart solution that one day I will have to reverse-engineer and fight to get my work done.