refactor: Use ItemIdentifierStack in ItemStackRenderer #40
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
... instead of ItemStack and cache EntityItem. The current code has an `entiyItem` field on ItemStackRenderer. But for the use case of the rendering items in pipes we only use a single ItemStackRenderer so the `entityItem` is actually never re-used and we create a fresh instance. This means in essence we create a new `EntityItem` instance every time an item travels down a pipe. To optimize for the `renderInWorld` case of a single ItemStackRenderer, we cache a single EntityItem used for rendering each item. To aid in this we refactor ItemStackRenderer to use an `ItemIdentifierStack` instead of an `ItemStack`. Most users of `ItemStackRenderer` use IdentifierStacks anyway. The result is a small bump in FPS when lots of different items are traveling at the same time and less pressure on the GC for all the temporary `EntityItem`s.
|
I can split it into two PRs for easier review if preferred. |
|
Please, use consistent naming for item stacks and item identifiers. I got myself confused a few times while reading code before I found that |
|
Good idea, thanks for the review! |
OneEyeMaker
approved these changes
May 19, 2024
szuend
added a commit
to szuend/LogisticsPipes
that referenced
this pull request
May 20, 2024
For doRenderItem there is no need to convert first to an ItemStack and then back to an ItemIdentifierStack on the hotpath if we can just pass the ItemIdentifierStack directly. This is a follow up to GTNewHorizons#40.
Dream-Master
pushed a commit
that referenced
this pull request
May 20, 2024
* refactor: Use ItemIdentifierStack in ItemStackRenderer ... instead of ItemStack and cache EntityItem. The current code has an `entiyItem` field on ItemStackRenderer. But for the use case of the rendering items in pipes we only use a single ItemStackRenderer so the `entityItem` is actually never re-used and we create a fresh instance. This means in essence we create a new `EntityItem` instance every time an item travels down a pipe. To optimize for the `renderInWorld` case of a single ItemStackRenderer, we cache a single EntityItem used for rendering each item. To aid in this we refactor ItemStackRenderer to use an `ItemIdentifierStack` instead of an `ItemStack`. Most users of `ItemStackRenderer` use IdentifierStacks anyway. The result is a small bump in FPS when lots of different items are traveling at the same time and less pressure on the GC for all the temporary `EntityItem`s. * Use itemIdentifierStack vs itemStack consistently in ItemStackRenderer.java (cherry picked from commit b020c30)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
... instead of ItemStack and cache EntityItem.
The current code has an
entiyItemfield on ItemStackRenderer. But for the use case of rendering items in pipes we only use a single ItemStackRenderer so theentityItemis actually never re-used and we create a fresh instance. This means in essence we create a newEntityIteminstance every time an item travels down a pipe.To optimize for the
renderInWorldcase of a single ItemStackRenderer, we cache one EntityItem for each item. To aid in this we refactor ItemStackRenderer to use anItemIdentifierStackinstead of anItemStack. Most users ofItemStackRendereruse IdentifierStacks anyway.The result is a small (but noticable) bump in FPS when lots of different items are traveling at the same time and less pressure on the GC for all the temporary
EntityItems.