Benjamin Kirk wrote: > Really good question. I'd like to look into it, if for no other reason > because we use it inside the DofObjects to create 2D arrays. John brought > up the point that packing into a single vector may use the same memory or > even less.
Or override new(). We have a lot of allocations which each request the same known numbers of bytes (based on system numbers, variable numbers, etc), which is in theory one of the circumstances where you might be able to beat the built-in new(). > Similarly, when we allocate the neighbors array, somewhere the size of that > array is hidden so that delete [] can do its thing. Since we always know > its size I wonder if there is any way around that... Here we can't easily override new(), but we can replace new and delete calls with calls to something like a "pool" allocator class. I'm not saying we should do either of these things, but there are options. > So I dusted off an old C book and found bit fields, which seem perfect... I think so. > The only thing that would have to change is that the few places we do this > kind of thing: > > elem->refinement_flag() = COARSEN; > > We'd have to change to > > elem->refinement_flag(COARSEN); > > Since you can't readily get a reference to the members of a bit field. You can get a reference to a RefinementState class whose operator= has been overridden to set the appropriate bit field entries. That's probably overkill for a fairly minor API change, though. --- Roy ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
