The Solidity repo wants to do a series of code refactors to improve the performance and reduce redundancy in the code base in preparation for its v0.5.1 release.
I tackled yet another one of those sub issues.
emplace_back instead of
Funnily enough, this was much simpler than removing the virtual statement in my previous post.
push_backin the search,
emplace_backin the replace
Built from source again, ran into some compilation problems. Reverted back to
push_back on the files that were complaining.
Pushed to repo, had issues with Travis, reverted again and pushed again.
This is still ongoing due to it being more complex than it seems.
There seems to be no real major difference between
emplace_back except for one real area:
Both copy over data and insert into the back of something. The key difference is that
push_back fails if you adjust the variables you’re inserting - so if it does not follow the exact pattern of how that objects variables are made (i.e. instead of three parameters being passed, you pass 2 and manually adjust the third to be empty), it fails to copy over the data.
emplace_back doesn’t. It will happily copy over the data without throwing a failure. In some very small use cases, emplace does speed up performance, but even that is nuanced and hard to find.
What I personally worried about with that is that Solidity handles sensitive data relating to currency. If you modify a particular value and emplace happily copies over it, it may be a vulnerability waiting to happen. I would rather it failed and forced the programmer to adjust to it, rather than vaguely copying over data.
So it’s back to the drawing board, hunting down where it does makes sense to use emplace. But hey, the PR got a shiny external contributor badge (so did the previous sub issue I posted about, but I digress). And I’ve been asked to keep working on it. It seems to be a more complicated performance based problem now, which sounds pretty cool to me.
Potentially a nice performance boost to the language.
The Pull request.