On Oct 27, 2009, at 3:33 AM, Tim Kroeger wrote: > I see. Anyway, at least it should be possible to replace some of the > pointers with ints or short ints (or perhaps chars). I mean, one > could make the arrays one-dimensional and then manage an array of > offsets for the systems instead. Since _n_v_comp and _dof_ids are > private in DofObject, the necessary changes should be manageable. Do > you agree? Would such a change be welcome if I implemented it?
This just feels like over optimization to me. We're talking about _Mega_ bytes here. I'm wary of making this more complicated / less understandable / slower to save MBs. But, it's not really my call either... > It would save some memory, but possible at the cost of time. I don't > know how often this information is accessed. If it is read in each > assembly, it could slow down things noticably. > > Still, there must be some other memory glutton in my application which > I have not found yet. Does anybody know how PETSc's memory > consumption behaves in 64-bit mode? Have you tried recompiling your application in 32-bit to make sure that's the problem? Even on a 64bit machine you can compile for a 32bit target and everything will run fine. Have you checked out older versions of your application and libMesh to make sure it wasn't some change that you were unaware of? I haven't noticed any large difference in memory usage in switching back and forth between 64bit and 32bit. On my mac I used to regularly build 32bit with gcc and 64bit with Intel and never saw a 30% difference in the memory usage of my application. I'm not saying it's not possible... but I do think you need to eliminate some variables before you drive yourself crazy chasing bytes... Derek ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
