That is a very nice suggestion!
I'll have a look at that, and see if I can hack a quick implementation.
It would probably be much better than my multi-map approach.
It felt like sort of a hack-fix on the current algorithm.
Doing all replacements in one run would also be really nice,
as my
On Fri, Dec 30, 2016 at 10:04 AM, Vladislav Egorov wrote:
> Oh, thanks! A very nice torture case. However, it seems to be related to
> another problem. The test case has no IF or LOOP blocks, so it can't be
> possibly improved with speeding up the cloning of the table (the
Oh, thanks! A very nice torture case. However, it seems to be related to
another problem. The test case has no IF or LOOP blocks, so it can't be
possibly improved with speeding up the cloning of the table (the torture
case can be modified with a few ifs and fors on top though...).
Anyway, on
On 12/30/2016 05:53 AM, Vladislav Egorov wrote:
I've looked into it recently (I'm working on series of many various
trivial optimizations)
and it's faster to just memcpy() it. Just throwing out superfluous
hashing still keeps slow
hash-table insertion around -- with resizing, rehashing,
I've looked into it recently (I'm working on series of many various
trivial optimizations)
and it's faster to just memcpy() it. Just throwing out superfluous
hashing still keeps slow
hash-table insertion around -- with resizing, rehashing, memory
allocation/deallocation, internal