View Full Version : Page Jump Slooooooow

November 11th, 2008, 06:01 PM
I'm designing a strip chart recorder for the ElkM1EZ8 plugin that logs when motion occurs in a certain zone within a given time slot. To graph this, I use a loop frame with a bunch of one pixel frames that have states representing motion or no-motion by color. I've attached a CCF & Lua file to illustrate what I'm after (work in progress).

Here is the problem- When I jump to the "Motion" page, there is a long delay and CPU usage jumps to 100%. After many seconds, the jump completes. I'm guessing there is a fair amount of computation associated with executing the Lua code to figure out the state values, but still, this seems to take way too long to execute such simple code. Where is the delay coming from?

Another clue- When you try and jump back to the "Home" page, you'll experience the same delay. While not present in the attached example, jumps to other pages do not experience any delay.

Rob H
November 12th, 2008, 03:41 AM
You're not wrong about it being slow! I'll take a look.

I can't say I'm surprised about the slowness, you're really making NR work very hard there. However, having said that, it's symptomatic of there being a linear search in there somewhere rather than e.g. a hashed lookup.

Presumably this is intended to give a history of the motion detection over time?

Rob H
November 12th, 2008, 06:32 AM
Well, I've managed to speed things up a little bit, but I think part of the problem is the loop loading code - I'll see if I can improve that in some way.

Then there's the problem of how long it takes to draw a page with that many elements on it - not sure how much of an improvement I can make there.

However, how on earth do you put up with the NRD load time? You're creating just under 24,000 NR variables. It takes ages to load NRD with that many variables. I've managed to just about halve the load time once I discovered that NRD was loading the NR variables twice at startup. I'll try to improve that too.

It's always good to have a degenerate case to work with, and this is certainly that.

For the moment I would probably suggest that you do things differently and don't present the full history. Perhaps you could have a detail button instead of the chart for each sensor that would take you to another page (or pop up a frame) which contained a single loop frame just for the selected sensor. That should perform much better.

November 12th, 2008, 11:24 AM
Hi Rob! Yes, the objective is to give a visual history of motion over time. The intent is to extend the inner loop from the present 73 elements to 720 elements so they extend the full width of the time line bar. This full 720px width then represents a rolling 24 hour window and each 1px bar represents 2 minutes. I'll have Lua code on the Girder side monitoring all the Elk zones for changes within this 2 minute window which will then toggle the 1px state frame accordingly.

Re. NRD load time, most of my CCFs have lots of variables but they are usually generated by Girder or later in NR Lua. So I'm used to long NRD load times. I usually exit Girder and NR to erase as many of these variables as possible. Then I start NRD and have it open NR. For the attached CCF, NRD takes only 3 minutes to load.

I can see the painting of the screen when the page loads and can live with the second or two that it takes. But the page jump delay of ~10 seconds seems a bit long. This would go to over 100 seconds if I were to go from 73 to 720 elements on the inner loop frame. I'm glad you are finding some opportunities to make this more efficient.

Rob H
November 12th, 2008, 01:48 PM
I suspect that the delay may be much more than 100 seconds if my suspicions are correct.

November 12th, 2008, 07:56 PM
Geometric versus linear, eh?
BTW, I discovered the Lua file was still generating the full 720 NR names in the child loop frame each of the 32 parent loop frames. Changing the FOR loop to 73 in Lua may shorten the NRD load time. Ironically, changing this from 720 to 73 did nothing to improve the page jump time. So the problem must be in the CCF variable comparison where there are only 73 state rules to compare for each parent frame.

I also created a CCF without the child frames. Instead, I created 32 individual loop frames manually numbered .x.<LoopIndex> instead of .<^LoopIndex>.<LoopIndex> for the state frame variable. This had NO impact on page jump times. I hope this helps you zero in on the problem.

Rob H
November 13th, 2008, 04:35 AM
The problem may be the way that NR loads looped frames - it currently seeks to the offset of the frame's child in the file for each child and reprocesses it. I'm not very happy with this scheme so I'll see if I can just make clones instead, that may be quicker. There is caching in place so it's not quite as bad as it used to be, but it's still not ideal.

Rob H
November 26th, 2008, 06:32 AM
I was, in fact, entirely wrong about the cause of the slowness here. I have now run the code under a profiler to confirm this.

What is actually happening is that each of the little segments of your chart is creating a window - this is because the background is not transparent so NR thinks that it's safe to create a window for it.

If you make the background of the default state transparent on the other hand you can have 720 segments per line and the page will load in fairly short order (about 1 or 2 seconds here). You can make the background of the parent black and achieve the same effect as you would have had with the default state's scheme of black.

January 7th, 2009, 12:36 AM
If you make the background of the default state transparent on the other hand you can have 720 segments per line and the page will load in fairly short order (about 1 or 2 seconds here). You can make the background of the parent black and achieve the same effect as you would have had with the default state's scheme of black.Thanks Rob. This worked great and the 1-2 second page jump is entirely acceptable.

I have a new problem. I'm posting here because you'll hate the time it takes NRD to load. I've done what you suggested plus added a time axis to the strip chart you saw before. See attached. The vertical white lines associated with the even hour markers are layered in NRD to be at the back. However, in NR they display on top of the black horizontal bar charts instead of behind them. How do I get this to display properly? Note that the vertical lines are one pixel wide state frames within one large 720 element loop frame.

Rob H
January 7th, 2009, 06:44 AM
That's a bit of a puzzler, I'll have to see what I can dig up.

January 16th, 2009, 06:37 PM
I recreated the problem page and it still doesn't layer correctly. I hope you are able to recreate the problem and find something.

February 7th, 2009, 06:08 PM
Rob, I have loaded NRD v2.0.0.9 and edited the vertical time lines to be in the back but they still appear in the front in NR. NRD load time and variable refresh time is still v e r y slow.

Rob H
February 7th, 2009, 08:01 PM
Nothing much I can do about the variable refresh time I don't think - you're just creating too many variables.