Closed samiebee43 closed 11 months ago
We ended up with about 7 minutes of program time for 20mb not 3-10 hours :(
start up time around 20mb is garbage, but it's not because of the file trimming code. That executed on a 60gb file instantly. (Good job, me). More info here: https://github.com/WasatchPhotonics/Wasatch.PY/pull/89
We may want to control Enlighten's boot time when the log is in the ballpark of 20mb, premerge. It's currently 1m 30s.
Thanks to the gray bubble in the splash screen, we can see that ResourceMonitorFeature seems to be the thing lagging in that case, but I don't see anything in that file that would reference the log. Notably, ResourceMonitorFeature is the first of "create_rest" in BusinessObjects
@mzieg Do you have any idea what may be lagging the boot ? It might be my program after all-- what would be a good way to test this?
Actually, since I don't have time to work on this and BLE at the same time, maybe we should just set the limit to 2mb for now and come back to it later ?
At least it will help with the case of "let me restart Enlighten real quick before sending the log to support", and it will provide us some surface to extend our log history later.
Now Wasatch.PY #93 is a prerequisite.
Using
--log-append=LIMIT
as the new default, Enlighten will append to the log file but keep it within a certain size.The size limit is decided by Wasatch.PY. Currently it is 20mb, but we want to tweak that based on a few things.
1) start up time. At 20mb it takes more than 60 seconds to open Enlighten. We want to keep launch sub, say, 35 seconds. 2) log coverage time. I'm aiming for 3-10 hours of program time if it's possible. 3) email attachment size. With a max of 25mb on most email clients, that's where 20 mb comes from (~5mb for last session, which may not have a program start truncation)