GeezerVison

CI: https://ci.nodejs.org/job/node-test-pull-request/41613/

What’s the harm though? I don’t have any use for the async context in my use case and the performance boost is kind of nice.

@ronag I mean ... it's more of a general principle that deprecated features a) should not add complexity to the code when avoidable and b) should not look like supported or encouraged use cases.

I don’t have any use for the async context in my use case

That might be true, but it seems like that's specific to your use case? Authors of addons cannot know whether their consumers use async tracking functionality or not (unless they are the same people, i.e. private addons, I guess), and Node.js has made it fairly clear that async tracking is a feature that the platform provides and that addons should support.

@addaleax, You listed the political arguments.
That mean that everyone has to pay a price for what they don't use, this is a weird policy (

@addaleax, You listed the political arguments.

She made the argument from the point of view of maintainability.

That mean that everyone has to pay a price for what they don't use, this is a weird policy (

Maybe I'm misunderstanding something but I took her argument to be the opposite: No cost should be incurred by the project maintainers to improve performance of deprecated features. That seems like a reasonable position for someone to take.

Maybe I'm misunderstanding something but I took her argument to be the opposite: No cost should be incurred by the project maintainers to improve performance of deprecated features. That seems like a reasonable position for someone to take.

No, here's the cost everyone pays, without this patch

No, here's the cost everyone pays, without this patch

That graph is comparing Node.js versions, and doesn't show what was actually being benchmarked. Unfortunately, that is not meaningful as data here.

And to say "everyone pays, without this patch" is misleadingly worded -- if there is a performance penalty without this patch (and I would assume there is because I assume that @ronag has benchmarked this), it is payed by people who use addons that use Node.js functionality in a deprecated way, not by everyone.

(And to be clear, this is not general opposition to performance improvements regarding MakeCallback.)

Unfortunately, that is not meaningful as data

@trevnorris did detailed benchmark of MakeCallback, does this count? https://gist.github.com/trevnorris/35c8e570c3097f58739b84bfa3f0a390

Which happens to match up exactly with Addon benchmark request per second / echos per second

Hopefully the trend has not continued downward, I have not done recent benchmark

does this count

@e3dio To be clear: What’s missing isn’t valid benchmarking data, it’s relevant benchmarking data. Of course it “counts” as valid benchmarking results; but it’s only data that can be taken to say “there is a performance issue”. It’s not data that can be taken to say “this PR meaningfully addresses that issue”.

Opened #41331, which also removes the overhead of pushing/popping async context, and does so in a way that actually benefits all users of MakeCallback().