search

NutritionalLungImmunity / nlisim

Apache License 2.0
11 stars 2 forks source link

Reconsider module executation time auditing #72

Open brianhelba opened 4 years ago

brianhelba commented 4 years ago

This capability was added as "costs" in #57

It was removed in #65 , as the implementation of adding data as Module instance variables and always outputting plot files was problematic.

brianhelba commented 4 years ago

Discussion so far:

@brianhelba said:

@jbeezley In general, if we do want to do profiling of module run times, what would you suggest?

@jbeezley said:

I have meant to run it through cProfile to find any fast optimizations. If you mean more like built-in infrastructure, I could see injecting timing information into the module state. I can't think of anything else off hand.

@brianhelba said:

@jbeezley @jmasison01 The removed "costs" functionality here captured end-to-end data on each module for high-level auditing (just recording the time taken by initialize and advance on a per-module basis). Would it be a good idea to facilitate this again in some way?

If so, one less-intrusive option would be to push this capability into another module which would record and report timings when it was active, but that would require some sort of event dispatch / hooks system, whereby the framework makes notifications before / after any module runs. That seems like a lot of infrastructure surface to support just this one feature.

Another option would be to keep the existing structure, but reconsider where the data is stored. Previously, it was attached to the Module instances themselves as an ordinary instance variable. Should this sort of meta-information be automatically added to the state of each module, or is there a better place?