Hi Vikas Chaudhary, the only difference from eventing / eventing-ee perspective across these two builds is a switch to Google V8 v10.7.21. This version of V8 libraries had deprecated some functions, so we had to change code to call the replacement functions instead. Apart from such changes to accommodate V8 SDK changes, there are no other Eventing logic change whatsoever.

As we already have discussed, the upgrade to V8 was expected to have a performance impact due to various checks being done withing V8 to determine use of V8 for attacks of various nature. As such, if the performance difference is due to V8 upgrade, that's just something we need to take as a hit - nothing can be done about it.

In this case, however, I feel the performance difference while partially will be due to the V8 upgrade, partially is also due to disk being slower. The test-case being identical across the two runs implies almost the same amount of data will be logged and written to disk. If in such a scenario, we are seeing disk-write-queue being larger, and disk-commit-time being more, that likely means that for some reason, the disk has been operating at a slower speed during the second run - could be due to fragmentation, for example.

Curious - do we run any command to trigger a disk defrag before run?

Vikas Chaudhary: I compared the performance numbers of these two builds, focussing specifically on the NOOP function execution and NOOP Timer executions. While there is a degradation, it does not appear to be much - within the tolerance limit. These tests do not perform any disk IO and are likely more representative of the actual V8 overhead across the V8 version involved. Thanks!

Srinivasan Raman Yes regression is marginal. We ran good and bad build both on the same disk without defragging. we can close it as expected or keep it open as minor. I will leave that to you. 

Thank you, Vikas Chaudhary...

In this case, there is actually nothing for us to fix. If this is a V8 issue, we will need to live with it. If this is a disk-slowdown issue, which is what I believe it to be, again, there is nothing for us to fix.

Question for you:
Is it possible to include a defrag step as a part of the setup prior to each test or test-suite? That will help eliminate performance issues that may come up due to disk fragmentation, which could skew a given test result.

Thanks!