search

nguy / artview

ARM Radar Toolkit Viewer
http://nguy.github.io/artview
BSD 3-Clause "New" or "Revised" License
48 stars 21 forks source link

Cache Vradar instances #93

Open nguy opened 9 years ago

nguy commented 9 years ago

An idea that came up at the AMS conference was potentially caching a limited (say 20?) Vradar instances as they are loaded if someone is navigating a directory. This would allow quicker loading of display if the graphics, etc. did not need to be rendered each time (imagine flipping back and forth).

We could make the filelist a dictionary and with None placeholders and replace with Vradar if the filename was called. Thoughts?

gamaanderson commented 9 years ago

first separating things, this would save us the time to open file, the graphics must be re-render any way, but this is fast (as fast as changing tilt) . I imagine it could also be possible to save the image, but from experience this get really complicated in the moment you notice there are several parameters that define an image (no just file).

About the suggested functionality it is nice, but I wouldn’t like it to be "artview-central" as it depend on what kind of use is being done. But that is not a problem, a long time I already think of developing a plug-in with more file opening functionality (including tree view of directories), this could go in there. Also notice that a plug-in can be started in script, so when the user open it is already there.

I should say however it is EXTREMELY memory need, pyart makes absolutely no attempt of saving memory, so some radar may take up to 1Gb, I already get my laptop stuck when trying to open just two of those. I would like to see pyart be more memory efficient but that will probably find some resistance.

Finally, nomenclature: I think we would be caching radar instances, not Vradar. This one stands for a Variable with a radar in it, it is kind of short for Variable(radar). Of course it is also possible to make a list of Vradar, but I see no need.

nguy commented 9 years ago

I see your points. Not sure it would make a big difference, except in specific data format types that take longer to read. And yes, Pyart makes no attempt to be memory efficient and that is fine. I'm actually pretty amazed at how fast ARTView runs now. It is completely dependent upon file size and type (whether the delay_loading can be used).

Sorry about the wording. You're of course correct that the radar instance is what would actually be stored, not the Variable. I don't think a list of Variables is a good idea as this would add unnecessary complexity.

gamaanderson commented 9 years ago

As I said, resistance! I'm obviously in the minority when it comes to memory efficiency :-(.

I'm not really amazed about ARTview speed, It is just fine, but I'm not ready to pay the cost of making it faster. What I don't like is how much time it takes (some times) to load PyQt and PyART, but that is python so that isn't much to be done.

Any way I will open a issue about the tree view of directory. It is already time of making it, may be we can even decide to make it "standard" and free the menu from much more development in IO.