Skip to content
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

PLY performance improvements #20

Open
LukasKalbertodt opened this issue Mar 27, 2019 · 0 comments
Open

PLY performance improvements #20

LukasKalbertodt opened this issue Mar 27, 2019 · 0 comments
Labels
area:IO Area: IO category:improvement Category: Improvement category:performance Category: performance/speed difficulty:hard Difficulty: hard priority:low Priority: Low status:ready Status: this issue can be worked on now

Comments

@LukasKalbertodt
Copy link
Owner

PLY reading and writing speed is not bad, but could be improved a lot. The difficult part is that PLY has a dynamic type system, so to say: we have to read the header to know what types to expect. This leads to a lot of complexity everywhere.

I have two main ideas how to improve PLY speed.

(a) RawSource has to be changed. Currently it is forced to write to the "serializer" once for each property. That means we cannot do any optimizations such as "have a temporary buffer with all vertex properties and write to the writer only once per vertex". This is bad. So this certainly needs to be improved.

(b) And here is where it gets funny: write a JIT codegen. The optimal assembly code to read "normal" binary PLY files is actually super simple. It's just a memcopy, mostly. However, due to the fact that the data layout is dynamic, the Rust compiler can't do any optimizations in that regard. So the idea is to generate x86-64 machine code after reading the PLY header. This code is then optimized for the PLY data layout. I bet this could increase raw read performance at least five-fold if not a lot more. But it's a lot of work and unsafe code and platform-dependent stuff and and and. Not sure if worth it -- it would be a super interesting project though.

@LukasKalbertodt LukasKalbertodt added category:improvement Category: Improvement priority:low Priority: Low T-weeks difficulty:hard Difficulty: hard area:IO Area: IO status:ready Status: this issue can be worked on now category:performance Category: performance/speed labels Mar 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:IO Area: IO category:improvement Category: Improvement category:performance Category: performance/speed difficulty:hard Difficulty: hard priority:low Priority: Low status:ready Status: this issue can be worked on now
Projects
None yet
Development

No branches or pull requests

1 participant