Jmol does not perform any heap memory allocation during the repaint cycle. For performance reasons, it is important that we continue to follow this guideline.
Detail ====== [Dave read a draft of this memo and gave permission to use his code as an example] In doing a little 'code review' of Dave's recently contributed code for Ribbons/Mesh, I saw something that is worth discussing. To be clear, Dave has written some excellent code. But with a small modification we can ensure that we maintain optimal performance. And I are going to use this code as an example to raise awareness of memory allocation issues in Jmol. To render the Ribbons, Dave needed two arrays of Point3i objects to hold the screen coordinates of the edges of his ribbons. So, he allocates the arrays and fills them up with new Point3i objects. Things get calculated, things get drawn, and nice-looking ribbons appear on the screen. And then the temporary objects get thrown away. And therein lies a small problem: temporary objects which we are allocating and discarding during the repaint cycle. Why is that a problem? Well, repaint cycles can occur rather quickly ... hopefully 30 times per second during rotations. So, if we are allocating objects out of the heap [by using new SomeObject(...)], then we can end up allocating a lot of them rather quickly. Actually, the problem is not with the allocation. The problem is with the *deallocation*; we are immediate discarding the objects. These discarded objects put unnecessary strain on the Java garbage collector, which must run through memory looking for discarded data structures. When the garbage collector runs it can sometimes generate pauses or 'hiccups' in the system response ... a bad thing. Therefore, we should address this by doing our best to 'recycle' memory objects during the repaint cycle. We can accomplish this by associating temporary objects with instances of the Renderer classes. We can ask the Renderer instances to allocate/store the temporary objects for us, and we can reuse the same temps every time through the repaint cycle. -- Interestingly, there are other parts of the system where this guideline does not really apply. For example, during IO operations we are free to allocate/discard almost as much junk as we want. During IO we need to do a lot of text parsing. This parsing generates many temporary strings that have very short lifetimes. But that is OK because we don't read files that frequently and because users expect it to be a relatively slow operation. Miguel ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
