Options
Minimizing Load Time
jjames
Posts: 2,908
I know that large programs take longer to load than smaller ones, but I'm looking for some tips and suggestions to minimize load times with the large jobs. A quick background as to how I program. I use a lot of arrays, and pointers; the arrays are typically no larger than the number of outputs of our switchers (typically 18, but in this case 64.) So, in this instance, I have a lot of integer arrays 64 in length. These are generally pointers - here's an example:
I have plenty of these large 64+ constant integer arrays. I have practically nothing in DEFINE_START, so I'm sure the load time is determined on creating these arrays and other things such as variables, etc.
I've been toying around with the idea of using virtual devices to hold the information (levels and channels.) In a project with 18 outputs, it's not a problem and is much easier to manage. Currently, it takes at least a minute or two do download the code onsite and then about 4-5 minutes of load time before the system is initialized. I'm not looking for a rewrite, but just ideas on how to handle this in the future. Would creating structures with all this information take longer, shorter or the same amount of time to load? Has anyone done any tests with load time, and using different ways of loading the data needed for the project? One thought was to use a CSV file and load that information variables whenever the device comes online, but not sure how well this would come out.
Tips? Suggestions? Ideas?
INTEGER nPDP_DEV_MAP[]=
{
0 // 1 Ellie's Bedroom
,0 // 2 Mackenzie's Bathroom
,0 // 3 Mackenzie's Bedroom
,0 // 4 Aiden's Bathroom
,0 // 5 Aiden's Bedroom
,0 // 6 Ellie's Bath
,0 // 7 Lower Floor Hallway
,0 // 8 Main Floor Hall
,0 // 9 Upper Floor Hall
,0 // 10 Media Room Intercom
,0 // 11 Master Bedroom Intercom
,0 // 12 Lookout Intercom
,0 // 13 Main Great Room Intercom
,0 // 14 Hearth Room Intercom
,0 // 15 Future Room
,0 // 16 Sue's Office
,0 // 17 Guest Bath
,0 // 18 Kitchen
,0 // 19 Exercise Room
,0 // 20 Master Bathroom
,0 // 21 Sue's Closet
,0 // 22 Wine Room
,0 // 23 Billiards
,0 // 24 Greg's Closet
,0 // 25 Garage
,0 // 26 Mud Room
,0 // 27 Utility Room
,0 // 28 Lower Bar
,0 // 29 Outdoor Lookout
,0 // 30 Loggia
,0 // 31 Study
,0 // 32 Upper Bar
,0 // 33 Pool Porch
,0 // 34 Master Bedroom Terrace
,0 // 35 Caban
,0 // 36 BBQ
,0 // 37 Master Bedroom Terrace
,0 // 38 Cabana
,0 // 39 Pool BBQ SPeakers 2
,0 // 40 Kitchen BBQ
,0 // 41 Basketball Court
,0 // 42 Landscape 1
,0 // 43 Landscape 2
,0 // 44 Landscape 3
,0 // 45 Landscape 4
,0 // 46 Landscape 5
,0 // 47 Main Great Room
,0 // 48 Dining Room
,0 // 49 MBR TV
,0 // 50 Kitchen TV
,0 // 51 Master Bath TV
,0 // 52 Media TV
,0 // 53 Snug TV
,0 // 54
,0 // 55
,0 // 56
,0 // 57
,0 // 58
,0 // 59 Steam
,0 // 60 Lookout DTR
,0 // 61 Media Room DTR
,1 // 62 Hearth Room DTR
,3 // 63 Master Bedroom DTR
,2 // 64 Family Room DTR
,0 // 65 Guest Suite
,0 // 66
}
// NUMBERS ABOVE POINT TO WHICH PDP TO USE...
DEV dv_PDP[]=
{
dvPDP1
,dvPDP2
,dvPDP3
//ETC.
}
I have plenty of these large 64+ constant integer arrays. I have practically nothing in DEFINE_START, so I'm sure the load time is determined on creating these arrays and other things such as variables, etc.
I've been toying around with the idea of using virtual devices to hold the information (levels and channels.) In a project with 18 outputs, it's not a problem and is much easier to manage. Currently, it takes at least a minute or two do download the code onsite and then about 4-5 minutes of load time before the system is initialized. I'm not looking for a rewrite, but just ideas on how to handle this in the future. Would creating structures with all this information take longer, shorter or the same amount of time to load? Has anyone done any tests with load time, and using different ways of loading the data needed for the project? One thought was to use a CSV file and load that information variables whenever the device comes online, but not sure how well this would come out.
Tips? Suggestions? Ideas?
0
Comments
This project does do M2M with 8 masters, not sure if that makes a difference.
Re: M2M, it won't slow boot time, but the system may not be completely ready until the other masters come online, depending on how you programmed the system.
In this case, I'm terrible with projector programming (I've never really got the hang of it), so I just looked for a module to slap in.
I don't think its the Duet module that's the issue per se, but that if you use any Duet modules then the Java runtime has to be loaded and started and this is likely what you are seeing slowing down a startup. Personally I am not so concerned about the startup costs, seeing as that is a rare occurence. It seems an odd thing to try and optimize but there might be a good reason to do so.
You don't specify what it is that is slow but if you are seeing slowness in the program like latency of feedback or other similar things, that is more likely due to the code or networking rather than Duet.
Paul
Load time to me is: the time it takes from reboot to DEFINE_START. If you open diagnostics, you can see when DEFINE_START is started. I initialize the system by shutting everything off after a reboot (I like to start fresh after a reboot), and usually put in a 10-15 second delay before things are shut off. On a smaller system (18 zones), it'll take anywhere between 60 seconds to 90 from code sent to "system ready". Here it's at least 5-6 minutes.
All that's happening in diagnostics during this time is the memory decreases for a while (which I assume is when the variables & constants are created.)
That's curious.
With the newest firmware all the LEDs flash once briefly when define_start is run for a visual confirmation as well.
5-6 minutes sounds like something is wrong. With no code running at all what load times are you seeing? I wonder if you have a flash drive that is on its way out, or a hardware address conflict or some other issue is going on. If you post your define_start code it might be helpful. I typically do very little in define_start so I don't know what effect having lots of code in define_start has on load times.
Paul
- Use DEFINE_START as little as possible. I moved almost everything out of DEFINE_START and into an ONLINE: section of a virtual device. DEFINE_START was executing before the processor was really ready to start handling things and it was pegging my buffers. I even had to add some delays in the ONLINE: section to make sure everything was ready for things like reading from the flash.
- If you have written modules the take in dev arrays of panels, be careful. Each instance of a module seems to create its own memory space or variable or pointer or something for tracking or use of the device. I once had a processor start time of over 40 minutes when I had 9 instances of a module that had a dev array of around 40 touch panels passed in. I moved the code from a module to an include modified to support all 9 devices and the boot time dropped back to 5 minutes. (Duet modules were still being used elsewhere)
- Make sure Duet memory is higher than the default 3M if you have ANY duet modules being used.
That is all that comes to mind at the moment, but I will edit if I think of something else. I also am not too concerned about boot times as long as the extra couple minutes has value when the program is running.
Jeff
13 Modules (I removed the Duet module for now)
8 Masters
Most (95%) code is run on this master, which includes variables, constants, etc.
When compiling, I get this: Prior to removing the Duet module, it was over 2MB of memory.
I loaded a "clean" program in, and it was much, much quicker (in the ballpark of 1 minute.)
I'll be honest, this is more of an annoyance, and not a job crippling problem. Once I'm complete and do not have to reboot as much - I'll probably forget the issue.
This is what I get until DEFINE_START...
Try not loading your modules and test startup and see if you can determine which one it is. There shouldn't be code executing yet so that's more of a cargo cult style approach than an intelligent guess.
Java is loaded anyway for the web interface even if no Duet modules are present.
One Duet module will slow the compile/boot time.