Quoting Timothy Driscoll <[EMAIL PROTECTED]>:
On Feb 16, 2006, at 5:01 p, [EMAIL PROTECTED] wrote:
I think that you are underestimating the requirements of my Jmol
interface. Take for example PDB entry '1OZT' (http://www.fli-
leibniz.de/cgi-bin/3d_mapping.pl?CODE=1OZT).
The slowest part is the labelling of all 502 "SAPs(SNPs)/Variants",
because they all must get an individual label, not definable by a
simple rule. I might be able to reduce the number of individual
labels to about 70 in this case, but in other cases with a single
chain there would be no reduction possible.
It takes about 45 seconds on my Laptop with a 1.6GHz Pentium M
processor (approximately equivalent to a 2 GHz Pentium 5) to set
and display all 502 labels. You can test this on your computer if
you first switch to the 'advanced interface', then switch off the
labels (if already shown) and finally switch the default labels for
"SAPs(SNPs)/Variants" on.
hi Rolf,
this only took a few seconds on my machine (667 MHz G4 PPC); perhaps
I missed a step? in any case, it seemed to work because a whole lot
of labels showed up (though I did not count them). :-)
I was quite surprised about this big difference. Therefore I suspected
some other reason than just CPU power and investigated this a little. I
noticed a browser and platform dependency on my laptop:
Linux:
Firefox -> 45s
WinXP:
Firefox -> 30s
IE -> 10s
It turned out that the efficiency of filling the message log textarea
seems to be mainly responsible for these differences. If I hide the log
these differences vanish almost completely (Firefox -> 6s, IE -> 7s).
Bob had already suggested a way to improve the logging mechanism, but I
hadn't taken the time yet to implement his suggestion.
instead of a history, though, how about a simple tab-delimited file,
one atom per line along with all of its attributes? in this case,
the maximum size of your saved view would be the size of the original
structure file.
Since a lot of additional information would be necessary to describe
all the properties it would certainly increase the file size (except
for small molecules where the existing annotation information exceeds
the atom coordinate information).
I agree that for the 'snapshot' function it would not be that
important to group the information, as long as the resulting dump file
wouldn't become too big (although it would still be nice).
But I think this is different for the 'current selection' information.
I would expect that it would affect the performance significantly if
you would for example either get back "chain A, chain B" or a list with
several thousand atom numbers.
Regards,
Rolf
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Jmol-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-users
