I'm doing some internal changes to the Elem class tree. The initial motivation: it turns out that one of our app codes hit a bug doing boundary solves on AMR meshes, whose fix means we need a real interior_parent() != parent() ASAP.
To do that without an extra 8 byte per element cost, the only solution was to tack an interior parent pointer on to the _neighbors array (now renamed _elemlinks, as John once pointed out this change would make the array name a bit of an atavism). Moving _parent to the same array would then save a pointer for us. I finally realized that if we keep our Elem* topology link arrays stored in subclasses, then the full result could be safer (no dynamic array lengths, so John's segfault and bounds checking worries for the accessor methods wouldn't be an issue) and even more efficient. We'd use the same or less memory overall and it wouldn't have to include heap memory anymore: we'd shave off a new() allocation per Elem. We can even get away with one less Elem pointer per Cell by always returning interior_parent()==NULL in that case, under the unfortunately-safe assumption that we won't be doing 4D meshes any time soon. And then I realized that I can do a similar trick with Node* links as fixed-length arrays; this removes another new() allocation per Elem. Between the two changes, we can now construct any Elem subclass without dynamic memory allocation at the Elem or subclass level. (the DofObject parent still naturally requires it, as does any _children allocation for AMR) Unless anyone is storing large numbers of Side or SideEdge proxy elements (which wouldn't have been a good idea to begin with...) this should be a win uniformly. Those classes are still proxies, but just barely... and I'm tempted to change even that eventually. IMHO the proxies' added cost in terms of requiring inline point/node functions to be virtual *everywhere* was always a bigger deal than their slight memory savings and cheaper constructors. Naturally, low level refactoring is a risky process; anyone trying to follow the svn head with production code ought to be prepared to revert to r4862 or r4863. Anyone following the svn head with regression testing code ought to scream at me when it catches anything. I won't commit anything that doesn't at least pass our example, unit, and app regression tests, but their coverage (even for the Elem class!) probably isn't pefect. --- Roy ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
