Mentat

If I understand correctly, currently there are two instances of mentat-inspector with diffent sets of rules. However, the rules from mentat-inspector-b are not dependent on attributes set by the first mentat-inspector. I tried to append the rules from the mentat-inspector-b to the rules of the first mentat-inspector, I removed the mentat-inspector-b from the pipe and it seems to be working. So this feature (nested rule chains) is not necessary to get rid of multiple instances of mentat-inspector.

Based on the phone call, I tried to run cProfile. I checked cbk_event_message_process from lib/mentat/daemon/component/inspector.py and I used 1000 and 10000 IDEA events so I am not sure if I did it right. Anyway, from what I can see, most of the time is spent in the pynspect module.

Rajmund Hruska wrote in #note-7:

Based on the phone call, I tried to run cProfile. I checked cbk_event_message_process from lib/mentat/daemon/component/inspector.py and I used 1000 and 10000 IDEA events so I am not sure if I did it right. Anyway, from what I can see, most of the time is spent in the pynspect module.

Which is expected result. However cumtime toplist does not say much, it times call of routine including all subroutines. What we would like to know is what is the hotspot, the bottleneck. If we end up in PLY, there's nothing we can do, if we end up somewhere in our code, there might be. So more interesting would probably be tottime or percall (excluding subroutines).

Also, interesting might be the simple throughput (how many events are we able to process, or how quick is one event processing), compared to other daemons - so we don't chase for optimisation with negligible effect.

Pavel Kácha wrote in #note-8:

Which is expected result. However cumtime toplist does not say much, it times call of routine including all subroutines. What we would like to know is what is the hotspot, the bottleneck. If we end up in PLY, there's nothing we can do, if we end up somewhere in our code, there might be. So more interesting would probably be tottime or percall (excluding subroutines).

I made a profile sorted by tottime of inspector with one set of rules and two inspectors for 1000 events, but to be honest, I don't know how to interpret the result. However, based on my previous reply #note-9, I think we can just use one inspector with one set of rules.

Rajmund Hruska wrote in #note-10:

Pavel Kácha wrote in #note-8:

Which is expected result. However cumtime toplist does not say much, it times call of routine including all subroutines. What we would like to know is what is the hotspot, the bottleneck. If we end up in PLY, there's nothing we can do, if we end up somewhere in our code, there might be. So more interesting would probably be tottime or percall (excluding subroutines).

I made a profile sorted by tottime of inspector with one set of rules and two inspectors for 1000 events, but to be honest, I don't know how to interpret the result. However, based on my previous reply #note-9, I think we can just use one inspector with one set of rules.

Tottime is the time spent in the function alone, without subcalls. So in my opinion it shows best where the most of the time is spent. So it might make sense to look to the routines at the top of the trace (in the pynspect), whether there's some low hanging fruit for optimization, or some apparent culprit (too much copying? "extend" instead of "for ... append"? less isinstance calls?). If not, we still have another options.

After discussion - let's try to merge the configs (#6949), we could also sometimes in the future look into pynspect optimizations (#6948), and let's defer this until we find out it's really needed.