Say, Rolf, when you get tired of that computer you are using, can you
send it to me? ;)
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.
>Additionally it would be necessary to be able to obtain information on
>the free and maximum available memory within Jmol (and what would become
>free if the currently loaded file(s) would be discarded).
>
>I know that there is the "_memory" variable that contains information on
>the free and used memory. But when I looked at the 3 different manually
>reachable sources for memory information ("context menu", "print
>_memory", "Java Console") after loading entry "1DEH"
>(http://www.fli-leibniz.de/cgi-bin/3d_mapping.pl?CODE=1deh) I got the
>following results:
>
> 1) context menu
> 18 MB total
> 6 MB free
> 254 MB maximum
>
> 2) print _memory
> 12.8/18.8
>
> 3) Java console
> 18,352 K
> 6,121 K free (33%)
>
>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.
> 2) print _memory
> 8.6/18.8
>
>
>
This is runtime.freeMemory() / runtime.totalMemory() in Mb
> 3) Java console
> 18,352 K
> 10,356 K free (56%)
>
>
>
This is probably also runtime.totalMemory() and runtime.freeMemory(),
although the numbers are a bit odd.
>So it looks as if the reported free memory does only take into account
>the currently allocated memory but not the maximum available memory.
>Therefore the maximum available memory should also be available within
>Jmol scripting.
>
>
only on systems implementing Swing (Java what version?) This is required
for the application but not the applet.
>And it would also be good to be able to request a garbage collection.
>(Avoiding false alarm because of calculation with wrong numbers.)
>
>Q: What do you think about storing the memory requirements for each file?
>
>
>
storing?
>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.
>While working with the extreme example '1m4x' I noticed that the CPU
>usage was almost all the time at 100% (refered to 1 CPU). Only if a
>screen update was necessary because for example a hidden part of the
>Jmol window became visible this went up to 200%.
>
>Q: Is there any way to benefit from multiple CPUs within Jmol?
>
>
>
I'm sure of it. We're hoping someday Miguel will take this on.
>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
>
>
--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr
If nature does not answer first what we want,
it is better to take what answer we get.
-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
-------------------------------------------------------------------------
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
