-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Miri is incredibly slow #14
Comments
I generally found miri to be slow if you're allocating a lot of memory. Personally I wouldn't worry too much since that's the nature of interepreter focused on correctness. Maybe there's a compile time constant we can tweak to make allocations under Miri smaller? |
Ok so I've actually narrowed it down a bit: allocations seem fine, and building large Vec's seems pretty quick now as well (I tried to use zeroed vecs where possible to avoid the Vec internals from calling clone). What is really slow is the Here's a version of the optimize method that has been augmented with some logging:
And a corresponding trace:
In this sample run, I feed it an all-zero set of This method is called 5 times when building a symbol table, and the time it takes doesn't vary with the size of the sample, so every time you call |
I've tried running Miri with
MIRI_LOG=info
, it generates several GBs of logs but if you filter formiri::machine
you get some simple enter/exit spans with timings. Still a bit hard to read, but at first glance some major contributors:codes_twobyte
Vec in the compressor. 65,536 element vector takes many seconds to build. And it gets rebuilt for every newCompressor
that is built during trainingoptimize
is where a lot of time in Miri is being spentI'll upload a miri trace once I compress it small enough to attach
The text was updated successfully, but these errors were encountered: