Improve performance

[disconnect3d]

This is a summary of performance improvements that we can try in Manticore:

• profile stuff and find bottlenecks
• If it is possible: remove assertions/optimize bytecode for pip build; otherwise remove them (as nobody launches python -OO and use type annotations instead and launch all tests with mypy (?)
• Remove properties for simple attributes - we overuse them and they may be 5x slower to access
• Use __slots__ especially for often/heavily accessed attributes
• Simplify __setstate__ and __getstate__: don't call it if it is empty and use trivial data structures (tuples)
• Removing all temporary fixed list creations (especially in asserts), and replacing them with uses of global tuples
• Rewrite almost all functional any, all, map, etc. uses in terms of simple for loops.
• Use enums for set of values instead of strings (e.g. ethereum's gas mode configuration is a string currently)

Some other ideas, called by @pgoodman that I am not 100% sure about:

• Making is so that serializing (via pickle) forked states was effectively O(1) cost in the N-solution case. Did this by saving the pre-fork, serialized state to disk, and making N-1 hard links to that file (for a total of N 'copies' of the original file for each of N forks), and then storing a state transition function in memory, so when you revive a state, you then apply the transition function to the unserialized state (e.g. concretize register EAX to value 10)
• Complete re-implementation of memory (probably not appropriate to port)
• Make it so that memory loads/stores never construct temporary list objects, and instead just re-use pre-defined list objects (one for each of 1-, 2-, 4-, 8-, 16-byte loads).
• Completely different system for event monitoring.
• Removed all uses of decorators.

Inspired by https://github.com/trailofbits/manticore/issues/757

[feliam]

Also. CoW and persisten object ID (for say pickle) will most likely dominate any other speed improvement trick in big/long runs. My bet is that currently the object copying/duplication and serialization is the bigger cause for slows there. Next in line is solver query no-optimization. Distant next is not lazy event system.

Any performance improvement trick that kill versatility will work against these more important things and should be approached carefully.

[ltfish]

Maybe you want to give PyPy a try.

[pgoodman]

Another low-hanging fruit optimization to try is to use a "magic" constant value for byte values in memory. Then, for all reads/writes, you opportunistically read the byte's present value, and if it matches the magic value, then you know that the value for that byte's concrete address is backed by the symbolic store. If a bytearray is used, then your magic value can be chosen by doing some profiling to find of distributions of byte values in memory for some runs, and then you still need a slow-path check to double-check if something is symbolically backed. If your memory is just a list of ints, then you can use a value like 257.