Closed Grinkers closed 7 months ago
I think the performance improves because move does a drop, and deallocating memory usually is expensive.
@naomijub @evaporei As you can see in the last commit, we have a circular dependency issue. I'm open to suggestions on how to get out of the deadlock with releases.
I think the performance improves because move does a drop, and deallocating memory usually is expensive.
In the example, it's not just dropping, but having to recreate it each loop too, essentially doing a clone()
each time. it's about half of the cost in this benchmark.
@Grinkers Those pending actions are not configured anywhere else, it might be from when the PR was created. Let me know when to merge and I can force merge it. Don't know how to clean it from the pipeline
I managed to fix them
I'm going to merge, with the TODO. It's needed because of the circular dependency (one of the two repos will need a temporary pointer. it makes sense to keep it here, as this is the one initiating the breaking change). After derive PRs, I'll clean it up as we progress.
This is a breaking change to Serialize and
edn-derive
. See https://github.com/edn-rs/edn-derive/pull/37 for compatibility. Clean-history version of https://github.com/edn-rs/edn-rs/pull/137Rationale: We want to be able to do things like
It is both annoying and potentially very expensive to move the struct, deallocate, and then create a whole new one each time you may want to serialize. If your Serializable data is inside of another struct, that requires a huge amount of work (making sure things can be
Clone
d, do deep copies, etc just to free it immediately after. In embedded this is probably critical, as you'll need the original, clone, and string data before starting to clean up, so max memory usage will high.As far as performance goes https://github.com/edn-rs/edn-rs/pull/144/files#diff-684ad70dd994bef2eaab407a0147b7b4ec3922c586fa15f9fe015d848abfc963L53-R54
This shows how expensive move vs borrow is (will continue to scale up depending on size).