Skip to main content
25 events
when toggle format what by license comment
S Nov 25, 2014 at 7:43 history bounty ended g3kk0
S Nov 25, 2014 at 7:43 history notice removed g3kk0
Nov 18, 2014 at 17:02 comment added Daniel Lichtblau Reported as a bug.
Nov 18, 2014 at 15:42 vote accept g3kk0
Nov 17, 2014 at 20:35 answer added bobthechemist timeline score: 9
Nov 17, 2014 at 19:30 comment added bbgodfrey I ran the following sequence with versions 9.0.1 and 10.0.1:MemoryInUse[] image = Import["ExampleData/CTengine.tiff", "Image3D"] MemoryInUse[] GaussianFilter[image, 1]; MemoryInUse[]. For version 10, the three memory numbers were 24600632, 35537848, 124676320. Thus, my computer consumed even more memory than the result given by @g3kk0. Next, I save the file and ran it with version 9, obtaining 26650296, 39502464, 97985304. Finally, I recreated the file and ran it on version 9, obtaining 25525112, 45144176, 104086784.
Nov 17, 2014 at 19:26 comment added bobthechemist I can't reproduce this error on v9 (Windows 7 64 bit). I don't have access to v10; however the problem does appear on WPC.
Nov 17, 2014 at 18:32 comment added Yves Klett I'd also suggest contacting support and/or posting on community.wolfram.com.
Nov 17, 2014 at 16:52 comment added g3kk0 Not yet. I still think that I might do something wrong.
Nov 17, 2014 at 16:50 comment added Michael E2 Have you asked WRI?
Nov 17, 2014 at 16:15 history edited g3kk0 CC BY-SA 3.0
added 540 characters in body
S Nov 17, 2014 at 16:08 history bounty started g3kk0
S Nov 17, 2014 at 16:08 history notice added g3kk0 Canonical answer required
Nov 11, 2014 at 2:59 history tweeted twitter.com/#!/StackMma/status/532004598806880256
Nov 10, 2014 at 16:30 comment added g3kk0 Thanks. Never heard of the function Share before. I added it but it doesn't seem to have an effect... unfortunately...
Nov 10, 2014 at 16:27 comment added Dr. belisarius You may also try Share[]
Nov 10, 2014 at 15:50 comment added g3kk0 Could be an interesting idea, thanks. Unfortunately, I don't have version 9 installed to try that with another version than 10. I tried the code using UndoOptions but it doesn't seem to have any effect. Memory is still leaking...
Nov 10, 2014 at 15:44 comment added DumpsterDoofus Is this version-dependent? I recently asked a question about a memory growth problem that turned out to occur because of V10's undo feature. However, in this case I'm not sure it's applicable because there is no output in your code.
Nov 10, 2014 at 15:13 comment added g3kk0 I applied it several times using Map and Table and the memory consumption raises in each iteration. If i would run it long enough it would certainly kill my computer (which it did already in the real program I use this line). So it never stops or returns the memory...
Nov 10, 2014 at 15:08 comment added kirma Does this continue indeterminately, or is there a cap after which use of memory doesn't raise any more? Nothing really guarantees that garbage collectors return conceptually vacant memory right away, and there are many use cases where this makes sense (especially if the collection is not based on reference counting). It may be a bug, but it may also be an internal implementation detail of the collector, for instance considering garbage collection only every N object allocations.
Nov 10, 2014 at 15:05 comment added g3kk0 quite a bit of RAM available, yes. But at some point even 96 GB are gone ... ;)
Nov 10, 2014 at 15:03 history edited g3kk0 CC BY-SA 3.0
added 188 characters in body
Nov 10, 2014 at 15:02 comment added g3kk0 Thanks for your fast reply. No doesn't have any effect. I will add it directly. It seems that the filter just soaks up my memory ;)
Nov 10, 2014 at 14:56 comment added Yves Klett Wow, quite a bit of RAM available there ;-) Does changing $HistoryLength=0 show any effect?
Nov 10, 2014 at 14:49 history asked g3kk0 CC BY-SA 3.0