View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002640||Slicer4||Core: Base Code||public||2012-10-14 06:53||2013-07-08 09:38|
|Product Version||Slicer 4.1.1|
|Target Version||Fixed in Version|
|Summary||0002640: Feature request: Memory compression|
To allow for loading numerous volumes in Slicer I think it would be a good idea to implement an optional zram like caching + compression method.(http://code.google.com/p/compcache/)
Since the nii.gz format is often able to reduce the footprint of images considerably (in my database often by 90%) this would lead to a more efficient memory management and in memory contrained (which is in my epxerience everything below 8gb of ram) systems to a speedup.
|Tags||No tags attached.|
Interesting idea - agreed that we are not particularly efficient in terms of memory use inside slicer.
There are a few considerations:
Yes, actually I have already tried it on a older C2D 4gb machine. A similar calculation on my 8gb machine would take up around 6 gb of ram. Using zRam I saw a speedup of around 50% because of the reduced/non existent swapping.
The implementation uses a very light form of compression. Since many of the datasets include relatively lots of 0000's the break-even point between compression/cpu load is attractive. But ofcourse you are right. Also on the conclusion that a system level implementation would be better (and as a module faster). But windows/mac do not allow for this kind of memory management easily.
As you have mentioned you could write a seperate routine for it in get/set image data to make it transparent.
|2012-10-14 06:53||almar||New Issue|
|2012-10-14 06:53||almar||Status||new => assigned|
|2012-10-14 06:53||almar||Assigned To||=> pieper|
|2012-10-15 05:01||pieper||Note Added: 0006525|
|2012-10-15 05:57||almar||Note Added: 0006527|
|2012-12-08 10:12||jcfr||Target Version||=> Slicer 4.3.0|
|2013-07-08 09:38||pieper||Severity||tweak => feature|
|2013-07-08 09:38||pieper||Target Version||Slicer 4.3.0 =>|