> Most of the memory (~94% by the end of the run) seems to be allocated > to > pixbuf structures (i.e. images), which is sort of understandable for > a > photo management application. 80% in gdk_pixbuf_new and the remainder > in > gdk_pixbuf_copy. However, the fact that it happens during an import > probably means they're all thumbnails as Shotwell creates them at > that time. > > Having said this, I'm not convinced memory usage is the root cause of > your problem.
Yeah, can agree, in fact it's not filling up system ram, even if this system has only 1Gb. > One thing I didn't ask you, which I should have: when it hangs, what > is > the CPU usage? Is Shotwell using 100% CPU or not that much? If it > uses > 100% CPU, it's probably stuck in an infinite loop somewhere. If not, > it > may be a threading issue. I wrote in my first post that it's hanging at 100%. when I captured the massif file shotwell was running at 100% cpu (on a single core, if matters). > The next thing to do would be to run it through valgrind again but > this > time using the helgrind or DRD tools to confirm what is happening in > terms of thread management and see if it locks itself out. Using the > callgrind tool could produce interesting output too. I haven't used > any > of those so can't really help on how to use them or interpret the > results but if you have data, we can always try to have a look see if > it > tells us something. I'm not familiar with valgrind too, but it's ok to run anything if can sort this out. Said that, if anyone has a more precise target to hunt (that is: tool) I'll be happy to report back. I'll open a ticket, in the meantime. -- Lorenzo Milesi - [email protected] GPG/PGP Key-Id: 0xE704E230 - http://keyserver.linux.it _______________________________________________ Shotwell mailing list [email protected] http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
