Hi Sascha,

Thank you very much for your answer!

> Your issues are hard to diagnose by their very nature.
Indeed, this is why im asking here because i thought someone might’ve come 
across something similar. 

> Are you using debug or release builds?
The problem is persistent in debug and release builds on both, Ubuntu 14.04LTS 
and MacOSX 10.9

> 32 or 64 bit builds?
64bit

> What is the amount of physical RAM on your machine?
I tried it on different machines. Happens on my laptop with 16GB (OSX), in a VM 
on said laptop with 8GB (Ubuntu 14.04) and on another machine with 32GB (Ubuntu 
14.04).

> Do you see an increase in swap space usage in the MITK case?

No, the swap behaves as expected. Meaning it will increase once the graph 
exceed physical memory limitations, no activity before that.

> Apart from memory fragmentation any maybe lots of cache misses in the MITK 
> case compared to the stand-alone CLI case, 

I do not have much experience in these matters, but the graph is allocated with 
1 call to malloc. afaik, this means the allocator will reserve 1 contiguous 
block in virtual memory and if this is not possible, it will return NULL. But 
the allocation works and is equally fast in both, the MITK plugin and 
standalone. To my understanding, fragmentation can’t be a problem since malloc 
guarantees contiguous memory? 

Cache misses are of course a problem to consider, but why should this only 
happen in the MITK context? 

Thanks again,
Thomas

On 30.11.2014, at 22:57, Sascha Zelzer <[email protected]> wrote:

> Hi Thomas,
> 
> MITK does not impose any restrictions on memory usage for plug-ins or any 
> other code. Your issues are hard to diagnose by their very nature. Are you 
> using debug or release builds? 32 or 64 bit builds? What is the amount of 
> physical RAM on your machine? Do you see an increase in swap space usage in 
> the MITK case?
> 
> Apart from memory fragmentation any maybe lots of cache misses in the MITK 
> case compared to the stand-alone CLI case, I can't think of any obvious 
> reason for the slow down.
> 
> Best,
> Sascha
> 
> On 11/26/2014 09:55 AM, Fitze Thomas (fitz) wrote:
>> Hey there
>> 
>> I’ve run into some problems with the way my MITK plugin behaves. What the 
>> plugin does, is asking the user for some parameters, choosing data sets and 
>> pass all the input to an ITK filter. This works for smaller (i’ll get back 
>> to what this means in a moment) images, but fails on larger ones. The ITK 
>> filter is a 3d graph cut segmentation filter developed previously. Important 
>> to know about graph cut segmentation is, that it allocates a big graph (1 
>> vertex for each voxel + neighborhood connections) and runs some calculations 
>> on it. To give you some feeling for how large these graphs are, the 
>> previously mentioned “smaller” image is be 122x255x299voxel which will 
>> result in 1813MB for the graph.
>> 
>> The calculation via the plugin for the small image takes ~15 seconds. This 
>> is about the same as the standalone (wrapped with a CLI application) ITK 
>> filter. However, once the image size increases, the MITK plugin will slow 
>> down significantly compared to the standalone. At a graph size of 2048MB 
>> (174x279x199 vox), the MITK plugin takes up to 100 seconds while the 
>> standalone is at around 50seconds. This gap will increase exponentially. It 
>> somewhat resembles the time complexity of the ITK filter once the graph gets 
>> bigger than the available physical memory (thrashing).
>> 
>> The calculations run in a QThread worker that i schedule via 
>> QThreadPool::globalInstance()->start(worker, QThread::HighPriority). I 
>> already tried removing the QThread overhead and starting the worker manually 
>> in the main plugin thread, this didn’t change anything (besides the GUI not 
>> updating, obviously…).
>> 
>> Does anybody have any idea what could cause this? Does MITK limit the amount 
>> of available memory to a plugin? I’d love to provide a minimal working 
>> example, but because the whole thing is rather complex and i’m somewhat 
>> short on time, i currently cannot provide one.
>> 
>> Thank you,
>> Thomas
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>> _______________________________________________
>> mitk-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/mitk-users
> 


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users

Reply via email to