Open holgerd77 opened 1 month ago
Hi Holger, thanks for writing this down. I was not aware that super
methods have such a performance impact!
The goal of the tx-refactor from my side actually has two goals which I want to tackle at once:
BaseTransaction
Might look like two separate tasks, but I did some quick-and-dirty experimenting and I think these two work well together. I want to open a proof-of-concept PR this week to show the general idea, it mainly consists expanding the Capabilities
idea which we already have in Tx to expand this to other redundant code, and to remove BaseTransaction
along altogether!
Sounds great! 🙂
Related: #3484
Today I looked into tx instantiation (thinking from client perspective where we consecutively instantiate thousands of txs), and results were quite suprising:
So these are times measuring the costs of the steps along tx construction (in total tx instantiation is quite noticeable, ~230ms for 10.000 txs, this comes together quickly). Notice the t1 step: this is for the
super()
call. I first thought: oh, something expensive insuper()
, but: no. Thes*
are actually the super measurements. This doesn't sum up. Turns out the costly thing is thesuper()
call itself. I stumbled upon this article on Netflix Tech Blog about general performance downsides of JS inheritance / super() calls.I think this information is likely primarily relevant in the context of the tx refactor, I therefore assigned @jochem-brouwer to this issue, more to take notice than to directly act upon. This might be another strong argument to generally get rid of the
BaseTransaction
(@jochem-brouwer, I think you already mentioned something like this? I also thought about this couple of times).