Evan Teran

possibly, it's worth trying. Could also switch to using a regex to parse the map instead of a long chain of if's, dunno if that would be faster or slower...

very good finds, I'll check out how to be apply some of these

BTW, how are you timing this? I want to make sure that I'm doing comparable tests (please be as specific as possible)

fair enough, I wonder if we can do some `rtdsc` stuff in the app itself to see how long it thinks it too. Dunno if it'll get messed up by...

So (hitting the BP and skipping 0x5000 times): with the `update_menu_state(RUNNING)` in: ~9000ms without the `update_menu_state(RUNNING)` in: ~6000ms A reduction of 30% is nothing to ignore, this indeed seems like...

Narrowing it down, it is specifically `edb::v1::set_status` that is occupying almost all of that 30%, looking into ways to make this better.

I did an experiment with boost hash, at least on my machine there was no measurable benefit for it. Since I the code has to at least look at each...

interesting, I think we can actually improve 1797fdd by using `boost::hash_combine`, instead of doing a hash of hashes. I'll play with it some more. Perhaps Qt IO is much slower...

I've pushed 634d182d that uses `boost::hash_combine` so it no longer needs to do heap allocations to get the total hash. On my system, It improved times by 50%!

One thing to note, is that my latest commit which makes `write_bytes` work in terms of `/proc//mem` has a speed regression here (I'm fairly certain it's due to this). My...