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

Release 1.0 #27

Open
wants to merge 1,250 commits into
base: master
Choose a base branch
from
Open

Release 1.0 #27

wants to merge 1,250 commits into from

Conversation

DaMatrix
Copy link
Member

the old pr (#10) was lost when i eradicated the primitive source from the git log, so i need a new one lol

@DaMatrix DaMatrix self-assigned this May 13, 2019
@DaMatrix DaMatrix changed the title Release 1.0 [WIP] Release 1.0 May 4, 2020
this uses the new recycled buffers in PorkUtil, and unaligned memory accesses in PUnsafe, both of which should have substantially better performance than the original code
this includes throwing exceptions in the places where they're supposed to be thrown, and not throwing them elsewhere
…zed arrays in a specific order

also, added some more unit tests to cover them.

honestly i'm surprised this hasn't popped up earlier: i've been using this code for years and never had a problem
also added some sub-types of AutoCloseable which make it possible to determine the exact exception type which will be thrown
this fixes some compilation bugs with newer javac versions
These work like C++20's std::bit_ceil(). They'll replace the existing roundToNearestPowerOfTwo() methods, which are slow, incorrectly named, and don't have documented behavior for values less than or equal to 0.
These are intended to be used by buffer or ArrayList-like classes to compute their new capacity when resizing to add elements.
This makes it clear how a value of 0 is handled.
This does technically affect their rounding behavior with values less than Integer/Long.MAX_VALUE, but I don't want to pollute all of my code with slow rounding code inherited from Mojang's bad coding style. Implementing these using standard library rounding functions reduces them to two instructions on all SSE4.1 hardware, and all my code which uses these methods was expecting them to behave like this anyway.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants