Bob Hanson wrote: > Rolf Huehne wrote: > >> Q: Could a "memory estimation function" be integrated into Jmol that >> would estimate the memory requirement prior to loading a specific >> structure file? >> >> >> > I think "prior to loading" is asking a lot. We've talked before about > possibly having a loading bar with a cancel option. An applet can know > how much memory is allocated, but I don't think it can know how much > overall is available, because as it needs more Java requests more. >
Q: Could at least a good rule of thumb for loading PDB format files be provided? (When I looked at a few examples, 20 times the uncompressed file size seemed to be adequate. But I would guess that it also depends somehow on the division into models, chains etc.. And it might also change with Java and OS versions.) Since we started processing all ~106,000 PDB files (asymmetric + biological units) for automatic image generation with Jmol we could export the memory requirement for each structure and put it into a database. But of course other users won't benefit from this solution. And it might be different on different machines and Java versions. (It takes about 2 days using 20 parallel processes on the machine Bob would also like to have. But leaving out '1M4X' because it might take 3 or 4 days alone to run it with the image generation script.) >> And after requesting a garbage collection within the Java console it >> changed to the following: >> >> 1) context menu >> 18 MB total >> 9 MB free >> 254 MB maximum >> >> > this is runtime.freeMemory(), runtime.totalMemory(), runtime.maxMemory() > > That last one is not available in some systems. > As always, false promises on platform independence, even with really basic important stuff... >> Q: What do you think about storing the memory requirements for each file? >> >> >> > storing? > Determine "runtime.totalMemory()" before loading a file (after removing the previous one if not "load APPEND") and after loading it and store it in a list variable for all files currently loaded. But if the values are available one could do this also with scripting. >> And since file loading is not the only memory consuming thing, it would >> be good to be able to obtain other memory information too. >> >From Bob's information about the high memory needs for >> 'antialiasDisplay' it looks like a good candidate for this. >> >> Q: Could a "memory estimation function" be integrated into Jmol that >> would estimate the additional memory requirement prior to 'set >> antialiasDisplay true'? >> >> >> > for the application, yes; for the applet, maybe not. > >> Since the "OUTO OF MEMORY" problem not only occurs with very large >> structures but for example also if a number of applets is started within >> a single browser session, I think this might be of general interest >> also to others. >> >> >> > very difficult in the applet situation, I think. > Yes, indeed! And if the freezing of our Jmol viewer occurs frequently I fear users will avoid using it in the future. Regards, Rolf ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Jmol-users mailing list Jmol-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jmol-users
