>>> 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. -Ben ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
