On Thu, Jul 17, 2014 at 10:37 PM, Andy Goth <andrew.m.g...@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/17/2014 3:22 PM, Stephan Beal wrote: > > in terms of memory use, it seems to be on par with lua, and lua is > > the lightest-memory interpreter i've yet run through valgrind. Most > > of them individually leak more memory than lua and s2 allocate > > combined. > > Sorry to drag this away from Fossil and TH1 and S2, but I suggest > running Tcl in Valgrind sometime. It's very, very good about memory > usage. > The parts it doesn't leak ;). i have not run any large-script tests on any interps except s2, but here are some valgrind numbers for _empty_ scripts on various interps on this ODroid box (copy/pasted from gdocs... format might get mangled): - lua allocates 299 times for 22093 bytes for an empty script. Fewer allocs than s2, but slightly more memory. i seem to remember (possibly incorrectly) that lua uses a memory region allocator, which would explain both lower allocation counts and larger memory usage. - JimTCL allocates 1665 times for 83444 bytes on an empty script. - tclsh: 143 allocs for 306KB, but it leaks 14 allocs and 216KB! It leaks more than s2, lua, and JimTCL allocate combined ;). Python 3.3.2: 23486 allocations (646 of which are leaked) totaling 3.8MB of RAM (344KB of which is leaked) for an empty script. The devs most definitely need to run it through valgrind - it reports over 580 different leaks and invalid memory accesses. (Granted, sometimes valgrind falsy identifies non-errors as errors, but i'm quite certain those are not all false positives.) Yup. Mangled. And note that empty-script costs (just measuring startup overhead) also tells a very incomplete picture, as startup memory costs don't necessarily have anything useful to imply about runtime costs. Aside from interim development versions, the only "leak" I've found is > a performance optimization in which it doesn't bother free()ing > everything on exit, much the same way Fossil doesn't clean up because > it knows the operating system will do it faster and better. There's a > That is most likely what is "leaking," and pedantically speaking that's not a leak, but i like to see libraries clean up. They shouldn't be using global state, IMO. > This is very important to me because I frequently use Tcl for testing > other code written in C and Fortran and such, and I need Valgrind to > spot my errors without being mired in the test harness. > > http://wiki.tcl.tk/3840 Aha. Thanks for that. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
