lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Fri, May 29, 2015 at 3:16 AM, Philipp Janda <> wrote:
I get about 140 MB in the "Hash-linked" `foreach_sum8` test on a 64-bit machine.

Thoughts? Am I approaching my measurements completely wrong?

For one, you are not measuring what you think you are measuring: The 140 MB is the memory used by 800000 closures with 3 unique upvalues each, created by the `lvalues()` function. (That's why the `foreach_sum8` test takes two times more memory than the `foreach_sum4` test, and 8 times more memory than the `foreach_sum1` tests.) The list elements are just noise in comparison ...

Wow, you are so very right. When I was writing this code, I knew there would be a penalty for closures with upvalues, but I figured, "Hey, they're pretty cheap... For a quick and dirty prototype this is probably fine!" But when you multiply "not very much" by 800,000, things start to add up quickly. I didn't actually do the math.

In my latest version,[1] I replaced lvalues() with eachcar(), which returns an iterator (an external local this time, instead of a generated closure). For the traditional pair-list, this returns the cdr (everything after the head, for non-lisp people) and the head value each iteration. This means I can use the list itself as the iteration variable with the generic for mechanism. This is closer to the analog of ipairs(), and runs WAY faster, with a tiny fraction of the memory. And in fact, for "Array-Tables" this actually just calls ipairs() for you.

I'm still seeing the issue where "Traditional" create10()  runs twice as fast and uses about 10% less memory if I comment out the other two tests before it. I'm thinking this has got to do with heap fragmentation, but I try to force the GC to clean that mess up between runs. Even if I set the backing store L to nil and run the GC a couple times, the results are the same.


Brigham Toskin