Significant slowdown on large files about happly

[xelatihy]

I took a look at that and it seems fine. Giving access to list properties directly will also help too (otherwise, we still get the constructor called many times). I took a crack at a similar thing in our library including adding helpers for loading points, lines, triangles, quads. For us, it works really well and scales well. If you care, I can e up a summary here of what one might want to do.

[nmwsharp]

This sounds like a good idea to me! There's a little extra complexity, but it's hidden from the user. And it makes total sense that it would speed things up.

[nmwsharp]

FYI, started working on this in https://github.com/nmwsharp/happly/tree/compressed_list

The core data structure for storing list properties is changed to a flat list in 82a5dd2. Seems to make just parsing in binary data ~40% faster.

Still need to expose direct access to the flat list via the API.

[nmwsharp]

Great! Agreed about direct access to the underlying buffers, can implement an API for that soon. Any tips you can share about helpers are certainly appreciated.

I spent a while looking at performance in happly a few weeks ago. Although some of the worst offenders (like nested std::vector allocs) can be cleaned up, ultimately the "simple" template-based approach happly uses holds it back from being ultra-fast. We just spend too much time in virtual function calls and streaming operators. Perhaps one day I'll find the time to rip out the insides and replace it with something faster, but for now happly will have to stay "medium speed" at best.

By the way, @mhalber has an awesome benchmark of ply reader/writers here: https://github.com/mhalber/ply_io_benchmark, if anyone is looking for something faster. At least happly does very well in terms of lines of code :)