Memory keep growing if I load a new dicom file - three.js

Every time I upload a dicom file, the memory grow up. How can I clean the memory of the old ones

You can see various examples of how to free the memory on the examples code, example on the loader:
let loader = new LoadersVolume();
loader.free(); // Free memory
loader = null;
Another one:
let stackHelper = new HelpersStack();
stackHelper.dispose(); // Free memory
stackHelper = null;
I suggest to read the following document to know how garbage collection works on most browsers.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_Management

The garbage collector deletes from the memory everything that is not referenced somewhere.
Having a high use of memory even if you don't you the object anymore means there still a reference to it somewhere. Look for a variable that can still access to your old data, including the 3D scene, the AMI stackHelper, the AMI loader...

Related

how to free a CPU buffer defined in halide

my projec used the buffer both in GPU and CPU.
code are similar like this:
xxx = HalideBuffer_n(width, heght, 1); // buffer in CPU
xxx.device_malloc(device); // buffer in GPU
PS: using HalideBuffer_n = Halide::Runtime::Buffer<uint8_t, 3>
i can use
xxx.device_free();
to free the buffer in GPU.
but which API can i choose to free the buffer in CPU?
i have used such as free or deallocate, but it seems dont work.
A Halide::Buffer is a shared pointer to the underlying allocation. xxx.deallocate() drops the reference to it. If this is the only copy of that HalideBuffer_n object then it will free the underlying memory too. If it's not freeing it means that another copy of that HalideBuffer_n object exists somewhere.

gsoap memory leak C applications

We are using gsoap for C client and server webservices implemented for blackfin running Linux.
We don't use any malloc in the application. But we see memory usage climbs over time. We are using soap_end to do a cleanup at the end of the call. But when the calls are invoked repeatedly memory usage slowly increasing, may be because of memory fragmentation. This is also impacting performance of the system
What's the preferred usage of gsoap where soap_malloc is not used much. For eg: If we use static arrays etc will it help?
Thanks,
nkr
I would not recommend using static data, there is no need for that.
To debug memory use, compile all your sources files with -DDEBUG. When you run your application you will see three files:
SENT.log the messages sent
RECV.log the messages received
TEST.log the debug log
The TEST.log is useful to check on messaging issues.
The other valuable information produced at runtime are error messages related to memory leaks or heap memory that is damaged (e.g. overruns) in your code. It is unlikely these will happen in the gSOAP engine, but better check.
To ensure proper allocation and deallocation of managed data:
soap_destroy(soap);
soap_end(soap);
I am using the auto-generated functions to allocate managed data:
SomeClass *obj = soap_new_SomeClass(soap);
and sporadically use soap_malloc for raw managed allocation, or to allocate an array of pointers, or a C string:
const char *s = soap_malloc(soap, 100);
but better is to allocate strings with:
std::string *s = soap_new_std__string(soap);
and arrays can be allocated with the second parameter, e.g. an array of 10 strings:
std::string *s = soap_new_std__string(soap, 10);
All managed allocations are deleted with soap_destroy() followed by soap_end(). After that, you can start allocating again and delete again, etc.
If you want to preserve data that otherwise gets deleted with these calls, use:
soap_unlink(soap, obj);
Now obj can be removed later with delete obj. But be aware that all pointer members in obj that point to managed data have become invalid after soap_destroy() and soap_end(). So you may have to invoke soap_unlink() on these members or risk dangling pointers.
A new cool feature of gSOAP is to generate deep copy and delete function for any data structures automatically, which saves a HUGE amount of coding time:
SomeClass *otherobj = soap_dup_SomeClass(NULL, obj);
This duplicates obj to unmanaged heap space. This is a deep copy that checks for cycles in the object graph and removes such cycles to avoid deletion issues. You can also duplicate the whole (cyclic) managed object to another context by using soap instead of NULL for the first argument of soap_dup_SomeClass.
To deep delete:
soap_del_SomeClass(obj);
This deletes obj but also the data pointed to by its members, and so on.
To use the soap_dup_X and soap_del_X functions use soapcpp2 with options -Ec and -Ed, respectively.
In principle, static and stack-allocated data can be serialized just as well. But consider using the managed heap instead.
Hope this helps.

Loading images takes my direct memory up | AS3

I'm only loading bitmaps, without even adding them to the stage, each image takes my direct memory up. Large images will take even more memory, so I'm wondering how to keep direct memory low even after loading those bitmaps, or maybe I'm doing here something wrong or missing something?
var myBitmapHolder:Bitmap;
var bitmapLoader:Loader = new Loader();
bitmapLoader.addEventListener(Event.COMPLETE, bitmapLoaded);
bitmapLoader.load(new URLRequest("myBitmap.png");
private function bitmapLoaded(e:Event):void {
myBitmapHolder = e.currentTarget.content;
}
After loading the bitmap, I'm storing it using myBitmapHolder to access it upon request. I'm using more than 30 bitmaps, works the same as the example above for each image separately.
so ... there is no free resource - you have to load all in the memory, or you have to load then unload each or few bitmaps. That will 'eat' some other resource like cpu and network traffic etc.
First you have to remove 'bitmapLoader' Event.COMPLETE listener in 'bitmapLoaded' function: bitmapLoader.removeEventListener(Event.COMPLETE, bitmapLoaded); } You have to be sure that you load the bitmap/s once. Look at this: AS3 - Memory management and What are good memory management techniques in Flash/as3. You can look at : imageDecodingPolicy also.

Out of Memory exception in Windows Mobile project

Dear programmers, i wrote a program wich target a Windows Mobile platform (NetCF 3.5).
My programm has a method of answers check and this method show dynamically created pictureboxes, textboxes and images in new form. Here is a method logic:
private void ShowAnswer()
{
PictureBox = new PictureBox();
PictureBox.BackColor = Color.Red;
PictureBox.Location = new Point(x,y);
PictureBox.Name = "Name";
PictureBox.Size = Size(w,h);
PictureBox.Image = new Bitmap(\\Image01.jpg);
}
My problem is in memory leaks or something. If the user work with a programm aproximately 30 minutes and run the ShowAnswer() method several times, Out of memry exception appears. I know that the reason may be in memory allocation of bitmaps, but i even handle the ShowAnswers form closing event and manually trying to release all controls resources and force a garbage collector:
foreach(Control cntrl in this.Controls)
{
cntrl.Dispose();
GC.Collect();
}
It seems like everything collects and disposes well, every time i check the taskmanager on my windows mobile device during the programm tests and see that memory were released and child form was closed properly, but in every ShowAnswer() method call and close i see a different memory amount in device taskmanager (somtimes it usues 7.5 Mb, sometimes 11.5, sometimes 9.5) any time its different, but it seems like sometimes when the method start to run as usual memory is not allocated and Out of memory exception appears.. Please advice me how to solve my problem.. Maybe i should use another Dispose methods, or i should set bitmap another way.. thank you in advance!!!
Depending on how you're handling the form generation, you might need to dispose of the old Image before loading a new one.
private void ShowAnswer()
{
PictureBox = new PictureBox();
PictureBox.BackColor = Color.Red;
PictureBox.Location = new Point(x,y);
PictureBox.Name = "Name";
PictureBox.Size = Size(w,h);
if(PictureBox.Image != null) //depending on how you construct the form
PictureBox.Image.Dispose();
PictureBox.Image = new Bitmap(\\Image01.jpg);
}
However, you should also check before you load the image that it's not so obscenely large that it munches up all of your device's memory.
Edit: I don't just mean the size of the compressed image in memory - I also mean the physical size of the image (height & width). The Bitmap will create an uncompressed image that will take up much, much more memory than is resident on storage memory (height*width*4). For a more in-depth explanation, check out the following SO question:
OutOfMemoryException loading big image to Bitmap object with the Compact Framework

IronPython memory usage

I'm hosting IronPython in a c#-based WebService to be able to provide custom extension scripts. However, I'm finding that memory usage sharply increases when I do simple load testing by executing the webservice repeatedly in a loop.
IronPython-1.1 implemented IDisposable on its objects so that you can dispose of them when they are done. The new IronPython-2 engine based on the DLR has no such concept.
From what I understood, everytime you execute a script in the ScriptEngine a new assembly is injected in the appdomain and can't be unloaded.
Is there any way around this?
You could try creating a new AppDomain every time you run one of your IronPython scripts. Although assebmlies cannot be unloaded from memory you can unload an AppDomain and this will allow you to get the injected assembly out of memory.
You need to disable the optimized code generation:
var runtime = Python.CreateRuntime();
var engine = runtime.GetEngine("py");
PythonCompilerOptions pco = (PythonCompilerOptions)engine.GetCompilerOptions();
pco.Module &= ~ModuleOptions.Optimized;
// this shouldn't leak now
while(true) {
var code = engine.CreateScriptSourceFromString("1.0+2.0").Compile(pco);
code.Execute();
}
Turns out, after aspnet_wp goes to about 500mb, the garbage collector kicks in and cleans out the mess. The memory usage then drops to about 20mb and steadily starts increasing again during load testing.
So there's no memory 'leak' as such.

Resources