On Tue, Aug 12, 2008 at 10:17 AM, Benjamin Kirk <benjamin.kirk@...> wrote:
>>>> Especially when T is a char - that is 24 bytes on a x86_64 in overhead!
>>> Yeah, because of the pointers... I believe sizeof(char) is still 1 on
>>> x86_64. That's pretty bad...
>> A more feasible option might be a single vector<char>. Then take the
>> current char** and align it out in a straight line in memory. I
>> believe the offsets into this vector are all well-defined given s,
>> n_vars, and n_components. There would be additional computation
>> overhead in determining the index, but the overhead of a single vector
>> with 3 pointers is comparable to the two pointers needed for a char**.
>> I guess this makes it more expensive to change the number of
>> variables in a system, since you'd have move everything down one or
>> two places...
> The changes between 0.6.2 and 0.6.3 have cut down memory requirements quite
> a bit, but there is still some more blood to squeeze out...
> I've thought about collapsing _n_v_comp (uchar**) and _dof_ids (uint**) into
> _dof_info (unit*), but as you say it gets more complicated to pack in
> multiple systems... Definitely do-able, though. Even in this case, though,
> the current approach (albeit a pain with the new/delete) only uses 1
> pointer+storage where a std::vector<> would use 3 pointers+storage.
I'm wondering about this actually. When you do:
_n_v_comp = new unsigned char* [this->n_systems()];
doesn't this create an array of n_systems() char* pointers? Granted,
you don't have the additional overhead of knowing the length and
capacity of each one, but it does appear that you will get more than 1
An in-between solution using a vector<char*> would mean you wouldn't
have to manage the outer memory (which is the easy part anyway) so I
don't like that one much. But writing a class which wraps a T** with
no additional overhead and provides a vector-like interface and memory
management might be pretty cool though. I'm guessing someone has done