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

Float16Array lookups appear to be much less performant compared to Float32Array lookups #781

Open
DLoh22 opened this issue Oct 10, 2022 · 3 comments
Labels

Comments

@DLoh22
Copy link

DLoh22 commented Oct 10, 2022

Hi,
I am using your library in hopes to cut down on memory consumption in my application. I have an array of floats with ~15 million entries, and I have found array lookups to be much slower since converting my Float32Array data type into a Float16Array.

I am trying to figure out if I am doing something incorrectly or if a performance hit is expected on lookups of an array of such a large size. Float16.js get() method is taking lots of time on my performance scans.

float_16_arr[i]; // much slower
float_32_arr[i]; // much faster

Thank you!

@zloirock
Copy link

It's logical. So sensitive to performance features like typed array magic is impossible to make so performant only in the userland as performant they can be done in engines internals. If you need them only for performance, it's better to avoid polyfills. However, they are fine for cases when performance is not so critical, you need them for something else like ToFloat16 conversion, backward compatibility, etc.

@petamoriken
Copy link
Owner

Unfortunately, Float16Array is not as fast in performance. Each time you get or write a value, it is converted by Proxy.

If you are concerned about performance, it is recommended to keep the data as a Uint16Array and use only getFloat16 and setFloat16 provided by this library.

@petamoriken
Copy link
Owner

FYI: https://github.com/tc39/proposal-float16array

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants
@zloirock @petamoriken @DLoh22 and others