Eyal Soha
Eyal Soha
Duplicate of #1151
It was to make a histogram, presumably for the purpose of analyzing statistics afterwards. Those statistics could help build a new Huffman tree for re-encoding data. But it's unused, yeah....
https://github.com/ilia3101/MLV-App/blob/ef8a955dc0f742e1890b83a355e8bd3b423cdad0/src/mlv/liblj92/lj92.c#L227 The lookup table is size 218 bytes! This is ridiculous! The cache misses are probably going to wreck the performance!
@masc4ii It can be optimized but the code is written quite poorly so I'd be wary of even trying it. The variable names are obtuse and everything is in c...
For my case, it's because I want to malloc the memory just once, then time the rest of the process. The malloc adds a lot of time to the program...
@PointKernel Yeah but only in the experimental code, right? I've got enough on my plate without switching over to be a guinea pig. :laughing: Perhaps port that to the non-experimental...
I'd like to avoid duplicating the work that cuco has already done. So if I can use the bulk operations, all the better!
The output iterator is a nice idea. No way it works with the memcpy_async, right? Surely memcpy_async requires that the destination is a real pointer. Worse still, it might compile...
I can test it very easily if you need. Let me know.
The complication with this adaptor is that the `key_equal` function depends on the which table is in the input. For example, say we are doing a bulk_insert followed by a...