Change to core to fix a billion #announceCurrentState messages
We found that whenever you have more than one transition at the end of a state in an experiment, the state system iterates between checking each of them. In the 0.4.3 codebase we have, this generates a new #announceCurrentState variable change for each type of transition, which gets logged.
This is the most braindead fix possible.
It reduces the size of the saved data files by about 50% in our
hands.
Let me know if you think this is wrongheaded.
Best
Mark
- core-announce.diff 1.89 KB
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by Christopher Sta... on 20 Apr, 2010 11:07 PM
Mark: I have to defer to Dave on this, since I don't yet know the MWorks core well enough to say whether this makes sense.
Dave: What do you think of Mark's patch? It looks to me like it disables not just the announcement of the state change, but the state change itself, which seems like a bad idea.
Thanks,
Chris
Support Staff 2 Posted by Christopher Sta... on 20 Apr, 2010 11:08 PM
Hey,
There are two separate things going on here:
1) From your diff, ANNOUNCE_CURRENT_STATE appears to be enabled in the version you are working against. This does not appear to be true anywhere (i.e. since the initial commit) in the mw_core repository (i.e. it is only true in your branch). You definitely want this OFF (undef'd), or it will spam the crap out of the console showing you all of the state transitions. This is a debugging feature, not something that should ever exist in a live system. I suspect that this accounts for a majority of your file bloat.
2) There's an open question about whether transitions ought to log themselves whenever they are evaluated. On one hand, it is nice from a fully-reconstruct-everything standpoint; on the other, transitions essentially "spinlock" looking for a condition to become true, so it can send a huge number of events to file if you spin for a long time.
I think a good solution would be to only log the event when the transition is followed (not when it is evaluated). This still allows one to reconstruct what happened (unlike removing the announcement altogether), without adding unnecessary waste during these spins (which, in a perfect world, would spin infinitely fast).
I just committed and pushed this fix as c4d54b0. Chris, perhaps you can cherry pick this and try it out with Mark?
– Dave
Support Staff 3 Posted by Christopher Sta... on 20 Apr, 2010 11:09 PM
Hey Mark,
Dave's fix to transition logging is now in the nightly build. Hopefully, this will eliminate the log file bloat you experienced. If not, please let me know.
Chris
Support Staff 4 Posted by Christopher Sta... on 20 Apr, 2010 11:09 PM
Ok we will check both things when we get a build running on our machines here. That's still estimated to be a few weeks from now. We can discuss when we meet.
thanks!!
Mark
Christopher Stawarz closed this discussion on 01 Jun, 2010 05:15 PM.