lua-users home
lua-l archive

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


On Tue, Apr 7, 2009 at 1:09 AM, Sam Roberts <vieuxtech@gmail.com> wrote:
> On Mon, Apr 6, 2009 at 4:14 PM, Matthew Wild <mwild1@gmail.com> wrote:
>> On Mon, Apr 6, 2009 at 11:41 PM, Fabien <fleutot+lua@gmail.com> wrote:
>>> There could be many definitions of "large tables", so you have to pick one,
>>> and implement the corresponding algorithm. For instance, what's the size of
>>> table { _G, _G } ?
>>>
>>
>> Obviously the size of the allocated table's header (no idea how Lua
>> represents this internally, so sorry if I'm mis-using terms) plus the
>> length of 2 references to another table (I presume all such references
>> are of a fixed size).
>
> So, you'd consider it the same size as
>
> table { string.rep("x", 10000000}, _G }
>

Yes, I would, assuming a reference to a table is the same size as a
reference to a string. In Lua strings are only stored once, the very
long string is a different object, and we would count its length
towards the total only once. But not only its length, but any overhead
involved in storing it.

> ?
>
> In that case, you appear to only care about number of entries in a
> table. You can count the size of the array part with
>  #t
>
> and use pairs() to iterate the table and find how many entries total,
> then subtract.
>
> Actual memory should be a small linear factor of that, you don't need
> byte usage, just tables that are excessively large, or so it sounds.
>

I'm sure it should be a linear factor, but I would take great delight
in knowing exactly what is using my bytes :)

I know which tables in my app are large, they are large because they
are meant to be large. But just knowing how many entries there are
gives me no clue to how much RAM they are using, as opposed to say the
internal string table.

I think the conclusion is that I need to spend some more time reading
the Lua sources, and figuring out the best solution for me from that.

Matthew