Closed MichaelRawson closed 1 month ago
Tag #157.
Preliminary run shows this is measurably worse. (Could this be because of vstring
though?) Maybe we should figure out which class of those affected is a least a bit hot and keep the special treatment only that one?
Bleh - it wasn't noticeably bad on the few things I tested here, so I hoped otherwise! I'll dig into it and do exactly that, it'd be nice to have this gone.
Measurable means "5" problems over the whole TPTP in -i 100000. But still, I'd consider this an opportunity to dig deeper.
Is it easy to work out which those 5 problems are? perf diff
is saying that this Vampire calls memset
a lot more from MLMatcher
, but I'm not really sure why or what to do with this information.
The 5 extra was actually 42 gained / 37 lost for the default strategy, i.e., with lrs. Will better come back (in a while) with a discount-based diff.
No problem in the diff for discount. Sorry for the false alarm. I think this can be promoted to the full extent.
Except maybe for the vstring, maybe we can keep it as a typedef to prevent another giant refactor?
Great! I'll eliminate most of this properly then. Agreed with vstring
. :-)
Should be ready for re-review. v(i|o)?stringstream
and various vcontainers
are no more, only vstring
remains. vvector
was a bit of a pain but is now also dead.
As discussed, also inline vstring
.
With the re-work of
Allocator
, it's possible thatSTLAllocator<T>
is no longer necessary either. This could have a performance impact as it calls into Vampire's small-object allocator, but I suspect it might be minimal or positive and @quickbeam123 was keen on the idea of no morevstring
.This is just the initial sketch: if it passes the performance question, I will clean up further.