I have rebuilt and rerun using 'libtool --mode=execute valgrind ...' and
the report looks quite similar:
==7672==
==7672== Total spacetime: 1,079,533,391,337 ms.B
==7672== heap: 89.9%
==7672== heap admin: 9.7%
==7672== stack(s): 0.2%
==7447==
==7447== Total spacetime: 1,332,042,060,276 ms.B
==7447== heap: 89.7%
==7447== heap admin: 7.6%
==7447== stack(s): 2.6%
Thanks.
Hong Yu
Sandro Santill wrote:
On Tue, Apr 29, 2008 at 04:24:13PM +0800, Hong Yu wrote:
Thanks for the suggestions! If jemalloc() option will be available soon,
we might soon try Gnash-cvs on ARM, together with the
GNASH_GC_TRIGGER_THRESHOLD=1 option.
We have run 'valgrind --tool=massif ./gtk-gnash <movie>' with our .swf
file on Ubuntu-edgy, and the conclusive report is (what does it indicate?):
==24736==
==24736== Total spacetime: 1,974,594,504,528 ms.B
==24736== heap: 90.5%
==24736== heap admin: 9.2%
==24736== stack(s): 0.1%
==18509==
==18509== Total spacetime: 1,337,694,253,067 ms.B
==18509== heap: 86.1%
==18509== heap admin: 11.2%
==18509== stack(s): 2.6%
The report above looks like coming from running a script, not a binary.
Make sure you use libtool --mode=execute if you're running the non-installed
gnash, and to run the gui-named version, as in:
libtool --mode=execute valgrind --tool=massif gui/gtk-gnash <movie>
On the other hand, we have also tried gprof profiling, and it seems that
graphics rendering animation takes considerable percentage of total
execution time on PC.
You were talking about memory before...
--strk;
_______________________________________________
Gnash-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnash-dev
_______________________________________________
Gnash-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnash-dev
