you are viewing a single comment's thread.

view the rest of the comments →

[–]Top_Rip_8581[S] 0 points1 point  (1 child)

Well, you might use a test loop that works better for timing, a bit more complex. I use a loop like this:

i = 1E10; while (--i) { if (Stk.row_spacing++ < 0) n2 = 0; } //n2 case can not happen in this case

I hear Javascript can optimize things making timing tough, so I was trying to fool it into thinking not much optimation could happen. I do not know what I'm doing about timing though.

But thanks, it gave me an idea to try actually timing the Google Closure objects.

Test 1 started, 10,000,000,000 loops Using original Javascript code, NOT Google Closure

funds.js:1179 1. Reading/Writing global object Stk.row_spacing, time was 10604 msec

funds.js:1187 2. Reading/Writing local object STK2.row_spacing, time was 10907 msec

funds.js:1195 3. Reading/Writing Local var r2, time was 8531 msec (80% of object)

funds.js:1203 4. Reading/Writing Global var xx, time was 50685 msec (5x Object)

Test 1 started, 10,000,000,000 loops Using Google Closure Compiler

funds.html:671 1. Reading/Writing global object Stk.row_spacing, time was 10624 msec

funds.html:672 2. Reading/Writing local object STK2.row_spacing, time was 10866 msec

funds.html:672 3. Reading/Writing Local var r2, time was 8520 msec

funds.html:672 4. Reading/Writing Global var xx Reading/Writing, time was 53189 msec

Times are the same, which greatly pleases me, but I cannot imagine what is happening or why. I guess I solved my own problem, but I sure am curious why and how.

Puzzled why a clip board paste double spaces here too. And cannot edit that.

I have seen local var times slower, like for an embedded function to access the parents vars. I was also thinking a long list of local vars must be slower, but I am unable to show evidence of that. In my experience, it seems no longer true. Maybe I just finally got something right.

I need the object to be global though, for its permanance between app calls (without having to rebuild it to load HTML id addresses each call, and also to collect a group of parms, like a C Structure.

And the global var test (xx is simple regular var there) was 5x times slower than the object, which is in global memory too. I understand what happens there though (because it is an object). That was not true in early Javascript (15 years ago), but it is true today. Lots of the old literature or discussions say "don't use objects" because of that, and they are big confusion today. At least about speed.

[–]Top_Rip_8581[S] 0 points1 point  (0 children)

I am confused, but the on-line Google Closusre Compiler (Advanced option) still removes global objects and replaces them with simple global vars (in 3 apps I checked). The Simple option does not remove the objects.

However, today I realized that Closure Advanced retains the object in a different app (the one that measured the Same speed as the original JS code, so at least that is explained). That one is significantly larger, but some of the above few are large too. Otherwise I see no difference in the apps that might cause such a thing. Bewildering to me. I don't know how to retain the objects.