benchmark: obj property access benchmark

[jasnell]

Benchmark that compares the obj property access patterns being
used in core today. Specifically comparing the two patterns:

function A() {};
function B() {};
var obj = {A, B, C: 1};

and

function A() {}
function B() {}
var obj = {};
obj.A = A;
obj.B = B;
obj.C = 1;

@mscdex @nodejs/benchmarking

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

Affected core subsystem(s)

benchmark

[Trott]

Am I the only one who is not a fan of including all those ES microbenchmarks in core? And now feeling a bit of trepidation about stuff like this in the es directory, which arguably isn't even an ES benchmark?

These all might be useful benchmarks, but I wonder if they might be better in some separate benchmarking repo.

I'd prefer the benchmarks bundled with core source be restricted to tracking actual node performance of actual core code in ways it will be used by actual end users.

Good benchmark to include in core: How many simultaneous http connections can we serve?

Less good IMO: Which of these two tiny contrived fixture modules is faster?

The results of this benchmark might be valid. Or real world results might vary quite a bit depending on use case. Because we never really know about the latter, I'd prefer we stick to benchmarking our actual use cases. Also, if this is going to cause a bunch of code churn for an improvement that isn't actually measurable in real code, then it may be creating more problems than it's solving.

If this is all just me and everybody else thinks including these types of benchmarks is somewhere between harmless and awesome, I will be a team player about it. :-D

[jasnell]

These are minimal impact (there's no harm in having them here) and they allow us to track the performance tradeoffs of code styles and language features that are actively used within core. They allow us to make better decisions about what kind of changes to land and when. I'd prefer to keep them... but then again, I'm the one that opened the PR so that part should be obvious :-)

[jasnell]

@nodejs/benchmarking @mscdex Thoughts on this?

[mscdex]

Why have this if it's the same in both direct/indirect cases?

[jasnell]

Which specifically? The obj.C bit? Basically checking any accumulative effect. It may not make sense to keep tho :-)

[jasnell]

.. by accumulative effect, I mean I want to measure the performance of all the accesses on the different module patterns.

[mscdex]

Yes, the obj.C is what I'm referring to.