As a closer, added a sort key to DevProf so that the device profile table assumes the same order as the device stats [the one with latest result at top]... seemed Spock logical to do that.

What I am/was contemplating is, if to add the device profile table updating needs to be part of the 12 hourly stats cycle. Right now there's a button on the ribbon to fetch at will, and that will remain, but how often does one change the device > profile association? I never do, each device has it's own profile [and that's more than 4], but maybe others flip it around often. Speak up and motivate... it's something slow to extract from the WCG... good old 20th century scrape, clean off agent images that come across, create/fit in table, extract DeviceId from urls, sort... a simple day in the boiler room so to speak, albeit fully automated but for the period routine inclusion.

ttyl

Well, as posted in the 'Something weird with the API' thread, finally made a bubble/binary search/check against the new ResultId field bend to my will and it running in 0.3 seconds for 6000 records looked up against 627K archive results instead of minutes.

Yesterday also toyed with the 'Is this a current period result or not' logic, and made it to just fetch the start time instead of start and end [we know a stats period is 43200 seconds long, so there's no need to fetch both :-). Today the literature revealed that VBA is a bit sloppy with clearing variables whence a procedure has ended, so if there's a function that needs to fetch a sheet value over and over again to, it can actually be kept in memory by declaring it public [noticed this before by accident when dealing with booleans, which confusionly kept returning True, when the default is False, forcing me to set the value back to false again at end of procedure [because it was public as it came out]. So now, with over 75000 results live [a never ending flood of FAHV shorts], used this slop and stored the PeriodStart value in a PrdStart variable, and put a test in the function... If PrdStart is 0 then put PeriodStart sheet value in PrdStart variable.

To think that before yesterday morning, the UDF function would have done sheet value fetching 150,000 times [75000 records times 2 for the start end period values], it now just does it 1 time just for the PeriodStart value only and then just flies away, ludicrous speed, If modtime - PrdStart is > 0 and <= 43200 seconds, then True (the result is for this period).

Adding to this, I've disabled result view filtering to just show all instead of only current period... the real time filtering in the table was just another CPU > GPU time eater continuously testing... has the result to be shown or not. Hardly worth considering when having 100-200-500 results live, but at the said 75000 update time needed piles up.

So much for the simple things that safe a bundle of time.

Oh dear, missed one other opportunity to pre-fetch a value to store as a session-constant and reuse it in a custom function. 6 Runs, alternating between with and without the constant and on current 6,500 results and 460,000 archive, exported half last night, a full model calculation rebuild took instead of 194 seconds [high 195, low 193], it takes 130 seconds [high 132, low 127]... ~33% speedup. That promises to be a significant time shaving when having 10s of thousands of shorts again.... considering the longest rebuild at max load of 76,500 results took 49 minutes another big shaving.

Have a nice e-ve-ning

Today was cracking the last of the hardest nuts [not required, just a nice challenge], and tried the hardest of the hardest first [since on this all of the rest would be build off]... the question was, how to read in an array without knowing whats in it, read it only once and NOT up to 107500 times, since the content is static for the duration of the stats period, and then find a match and an offset index entry, which led to discovering that VBA allows

Application.WorksheetFunction.Index
WorksheetFunction.Index
Application.Index

All 3 do exactly the same, where the beaute is, that to VBA it does not matter whether the data has to be fetched from the spreadsheet, or whether it's stored in an array, where latter is orders of magnitude faster, still regardless UDFs being single threaded where spreadsheet functions can often use multiple threads (if allowed).

Then, since the array was a mixture of text and datevalues, had to ensure that if it was a date, the number would be returned and not a string of said date, where the novel to me CDate came to the rescue and a simple test if the 3rd pos in the string is a - or not. simply resulted in

If Mid(Matchtest, 3, 1) = "-" then matchtest = CDate(Matchtest)

and voila we have a winner.

Set and done, ordering the ifs with the most probable outcome at top, and least probable at bottom and whilst before staring at the statusbar the calculating StatsPeriod indicator was pulsing and pulsing, another step has turned into being missed if blinking.

Am late for the bike ride, but could not hold this back any longer... Snooze BOINC, and the Hunting tool runs twice as fast, so scripted a shell instruction to boinccmd to suspend BOINC at start of a run and resume on finish... Not sure how 'polite' I will further view crunching on any business / school / gaming machine, let alone a server, but if an update cycle takes 16 minutes instead of 31 minutes and at work, I'd get very upset with that knowledge.

Still to investigate if instead setting % of processors to 75 at start through boinccmd, since the TaskManager shows the tool never uses more than 25% CPU resource on the octo in an 'allowed to use all cores' run, before final verdict, but for now have the client go into full pause when the scheduled runs take place.