This is JavaScript only.
On Tue, Dec 22, 2015 at 1:55 PM, Rolf Huehne wrote:
> On 12/22/2015 03:18 AM, Robert Hanson wrote:
> > BTW, that's because "{" will be read as a JavaScript statement grouping:
> >
> > {
> > var x = 3;
> > ...
> > }
> >
> > By putting "0," before that, you gua
On 12/22/2015 03:18 AM, Robert Hanson wrote:
> BTW, that's because "{" will be read as a JavaScript statement grouping:
>
> {
> var x = 3;
> ...
> }
>
> By putting "0," before that, you guarantee that it is read as an object.
>
> You can also use
>
> y = javascript('JSON.parse(\"'+x+'"\
BTW, that's because "{" will be read as a JavaScript statement grouping:
{
var x = 3;
...
}
By putting "0," before that, you guarantee that it is read as an object.
You can also use
y = javascript('JSON.parse(\"'+x+'"\")')
where x is JSON encoded. I could imagine that would be a bit fa
Javascript cannot eval("{test:'here'}")
add "0," before that.
On Mon, Dec 21, 2015 at 10:24 AM, Rolf Huehne
wrote:
> On 12/18/2015 06:41 PM, Robert Hanson wrote:
> > x = null
> > y = null
> > t = now();
> > x = load("tt.json")
> > print "ms to read " + x.length + " bytes: " + now(t)
> > t = n
On 12/18/2015 06:41 PM, Robert Hanson wrote:
> x = null
> y = null
> t = now();
> x = load("tt.json")
> print "ms to read " + x.length + " bytes: " + now(t)
> t = now()
> y = javascript(x)
> print "ms to translate JSON to Jmol variables: " + now(t)
>
> ms to read 58696197 bytes: 12313
> ms to trans
On Fri, Dec 18, 2015 at 3:13 PM, Rolf Huehne wrote:
> On 12/18/2015 10:00 PM, Robert Hanson wrote:
> > I'm not sure the Java data are significant -- all you are seeing there is
> > the overhead for executing JavaScript from Java. The Java itself has
> > nothing to do with it, since the loop is in
On 12/18/2015 10:00 PM, Robert Hanson wrote:
> I'm not sure the Java data are significant -- all you are seeing there is
> the overhead for executing JavaScript from Java. The Java itself has
> nothing to do with it, since the loop is in JavaScript.
>
But the 'performance.now()' calls are done insi
(but my results with this using slice() was about the same with Firefox.
n=100; a = new Array(n);
for (var i = a.length;--i >= 0;) {a[i] = i;}
t1=performance.now(); b = a.slice();
t2=performance.now(); c = new Array(n);
for (var i = a.length;--i >= 0;)
{ c[i] = a[i] }
t3=performance.now(); dt1
I'm not sure the Java data are significant -- all you are seeing there is
the overhead for executing JavaScript from Java. The Java itself has
nothing to do with it, since the loop is in JavaScript.
Note that you need to use .slice() not .slice(0). The latter just pulls
the first value out.
On F
On 12/18/2015 09:05 PM, Robert Hanson wrote:
> Oh, yes. .slice() copies all or part of an array.
>
The independence of 'n' was caused because the elements of the copied
array were all undefined. I have changed the test and filled the array
with values first:
Jmol script
According to jsperf ( https://jsperf.com/string-concatenation/106 ) your syntax
seems optimal.
> Le 18-12-2015 à 15:30, Robert Hanson a écrit :
>
> I was thinking of alternatives to
>
> s = "a" + "b" + "c"
>
>
-
I was thinking of alternatives to
s = "a" + "b" + "c"
On Fri, Dec 18, 2015 at 2:20 PM, Paul PILLOT wrote:
> Regarding strings, from what I experienced, getting a value from an array
> is a lot faster when the array is index based than when the array is
> associative (strings as indexes)
> Don
Regarding strings, from what I experienced, getting a value from an array is a
lot faster when the array is index based than when the array is associative
(strings as indexes)
Don’t know if that applies to your case...
Paul
> Le 18-12-2015 à 15:15, Robert Hanson a écrit :
>
> (the copy is the
(the copy is the same as System.arraycopy -- it only copies references for
objects, but it copies scalars such as integers and floats.)
On Fri, Dec 18, 2015 at 2:05 PM, Robert Hanson wrote:
> Oh, yes. .slice() copies all or part of an array.
>
> That's certainly a major improvement. Excellent. J
Oh, yes. .slice() copies all or part of an array.
That's certainly a major improvement. Excellent. Jsmol is now using
.slice() exclusively when possible.
I suspect some of that fast processing time is due to this use.
This is the kind of deep optimization that really have an effect. Great!
How a
On 12/18/2015 06:41 PM, Robert Hanson wrote:
> Rolf, let's try some tests. I noticed that 16 Mb of JSON code was turned
> into JavaScript in 1.5 seconds by the browser just using a script tag, so
> that parser is fantastic.
>
> Putting that much into Jmol variables would be a challenge, and I do
Rolf, let's try some tests. I noticed that 16 Mb of JSON code was turned
into JavaScript in 1.5 seconds by the browser just using a script tag, so
that parser is fantastic.
Putting that much into Jmol variables would be a challenge, and I do not
propose to be able to do it on that scale, but eve
On 12/17/2015 06:51 PM, Rolf Huehne wrote:
> Thank you for the hint, Bob.
> I have thought about using JSON format but couldn't find a way to read
> it in again in the documentation.
> And besides I had a lot of trouble with the JSON format in another
> project (Javascript->JSON->Perl-CGI->Filesyst
On 12/17/2015 07:28 PM, Robert Hanson wrote:
> On Thu, Dec 17, 2015 at 11:51 AM, Rolf Huehne
> wrote:
>
>>
>> - Error Message --
>> TypeError: b.lineNumbers is null try/catch path:
>> 0 function (b,d)
>>args[0]=TypeError: b.lineNumbers is null
>>args
On Thu, Dec 17, 2015 at 11:51 AM, Rolf Huehne
wrote:
>
> - Error Message --
> TypeError: b.lineNumbers is null try/catch path:
> 0 function (b,d)
> args[0]=TypeError: b.lineNumbers is null
> args[1]=function (){a.instantialize(this,arguments)}
> 1 JS.Sc
We should probably think about being able to switch back and forth between
Jmol variables and JavaScript variables without using JSON. At least for
the HTML5 version.
On Thu, Dec 17, 2015 at 11:04 AM, Robert Hanson wrote:
> If I were to be able to read that back into Jmol it would need to be in
On Thu, Dec 17, 2015 at 9:26 AM, Kubasik, Matthew A. wrote:
> Bob,
>
> Could you expand on your comment that “Jmol uses typed arrays when
> possible"?
>
> I am in the habit of initializing arrays with a line like:
>
> a=array()
>
> Should I be doing something else? Does the array get “typed” aft
On 12/17/2015 06:04 PM, Robert Hanson wrote:
> If I were to be able to read that back into Jmol it would need to be in
> JSON format. You would need to use:
>
> x = format("JSON",parsedData)
> write var x "t.json"
>
> and I am not certain that even then Jmol could read it, but if it could,
> it wo
If I were to be able to read that back into Jmol it would need to be in
JSON format. You would need to use:
x = format("JSON",parsedData)
write var x "t.json"
and I am not certain that even then Jmol could read it, but if it could,
it would be by using
y = eval(load("t.json"))
Maybe you can ex
On 12/17/2015 04:03 PM, Rolf Huehne wrote:
>> I think I cannot reveal the whole system yet, but I have placed here
>> (temporarily) the compressed output of 'write var ...' of the parsed data.
>>
> Sorry, I forgot the URL:
>
> http://jenalib.fli-leibniz.de/ImgLibPDB/tmp/parsed_data-2015_12_17.zip
>
Bob,
Could you expand on your comment that “Jmol uses typed arrays when possible"?
I am in the habit of initializing arrays with a line like:
a=array()
Should I be doing something else? Does the array get “typed” after I add an
entry?
Matt
On Dec 16, 2015, at 3:48 PM, Robert Hanson
mailto:
On 12/17/2015 03:54 PM, Rolf Huehne wrote:
> On 12/16/2015 09:48 PM, Robert Hanson wrote:
>> Jmol uses typed arrays when possible. Parsing of scripts is relatively
>> slow. Rolf, if you want to give me something to try, I will be happy to
>> play with it and see what I can learn.
>>
> Bob, what wou
On 12/16/2015 09:48 PM, Robert Hanson wrote:
> Jmol uses typed arrays when possible. Parsing of scripts is relatively
> slow. Rolf, if you want to give me something to try, I will be happy to
> play with it and see what I can learn.
>
Bob, what would you want to have?
I think I cannot reveal the w
Jmol uses typed arrays when possible. Parsing of scripts is relatively
slow. Rolf, if you want to give me something to try, I will be happy to
play with it and see what I can learn.
On Wed, Dec 16, 2015 at 12:30 PM, Paul PILLOT wrote:
> Hi Rolf,
> my experience in this area is not JSmol related,
On 12/16/2015 07:30 PM, Paul PILLOT wrote:
> Hi Rolf,
> my experience in this area is not JSmol related, but when I had to deal with
> big tables in javascript (for a multiple sequence alignment script, aligning
> 2 sequences of 5000 signs, requires at least 1 table of 5000 rows and 5000
> colum
Hi Rolf,
my experience in this area is not JSmol related, but when I had to deal with
big tables in javascript (for a multiple sequence alignment script, aligning 2
sequences of 5000 signs, requires at least 1 table of 5000 rows and 5000
columns), I noticed that :
- using integers only tables is
Hi all,
I am looking for some speedup tips for Jmol scripting in JSmol/HTML5.
The speed difference between JSmol/Java and JSmol/HTML5 for graphical
operations like rotation and zooming seems to be about 10 times or less
in Firefox and Chrome (if you don't consider the recent rotation speed
pro
32 matches
Mail list logo
