benchmark: complete the sqlite is-transaction fix

[geeksilva97]

This PR removes the Logical AND assignment. It was causing the benchmark to call the isTransaction only once when the getter was returning false.

With the deadCodeElimination being false, the right side never runs.

Before

$ ./node benchmark/sqlite/sqlite-is-transaction.js
sqlite/sqlite-is-transaction.js transaction="true" n=10000000: 64,634,434.23269218
sqlite/sqlite-is-transaction.js transaction="false" n=10000000: 871,137,051.6366488

After

$ ./node benchmark/sqlite/sqlite-is-transaction.js
sqlite/sqlite-is-transaction.js transaction="true" n=10000000: 64,021,357.52487029
sqlite/sqlite-is-transaction.js transaction="false" n=10000000: 66,274,377.580040805

[nodejs-github-bot]

Review requested:

• @nodejs/performance

[H4ad]

The initial idea was to assert this never returns invalid value due any optimization (such as fast apis)

But this works as well, thanks for the fix

[geeksilva97]

The initial idea was to assert this never returns invalid value due any optimization (such as fast apis)

But this works as well, thanks for the fix

No prob. Btw, this is my first time changing benchmark stuff. Do we need CI for it?

[github-actions]

Benchmark GHA (sqlite / sqlite-is-transaction): https://github.com/nodejs/node/actions/runs/31584406184

Results

[!WARNING]
Do not take GHA benchmark results as face value, always confirm them
using a dedicated machine, e.g. Jenkins CI.

Benchmark results:

 confidence improvement accuracy (*) (**) (***)
sqlite/sqlite-is-transaction.js transaction='false' n=10000000 0.06 % ±2.36% ±3.11% ±3.99%
sqlite/sqlite-is-transaction.js transaction='true' n=10000000 -0.62 % ±2.38% ±3.13% ±4.02%
Be aware that when doing many comparisons the risk of a false-positive
result increases. In this case, there are 2 comparisons, you can thus
expect the following amount of false-positive results:
0.10 false positives, when considering a 5% risk acceptance (*, **, ***),
0.02 false positives, when considering a 1% risk acceptance (**, ***),
0.00 false positives, when considering a 0.1% risk acceptance (***)

[!WARNING]
Do not take GHA benchmark results as face value, always confirm them
using a dedicated machine, e.g. Jenkins CI.

[nodejs-github-bot]

Landed in f914e45

[geeksilva97]

This PR removes the Logical AND assignment. It was causing the benchmark to call the isTransaction only once when the getter was returning false.

With the deadCodeElimination being false, the right side never runs.

Before

$ ./node benchmark/sqlite/sqlite-is-transaction.js
sqlite/sqlite-is-transaction.js transaction="true" n=10000000: 64,634,434.23269218
sqlite/sqlite-is-transaction.js transaction="false" n=10000000: 871,137,051.6366488

After

$ ./node benchmark/sqlite/sqlite-is-transaction.js
sqlite/sqlite-is-transaction.js transaction="true" n=10000000: 64,021,357.52487029
sqlite/sqlite-is-transaction.js transaction="false" n=10000000: 66,274,377.580040805

[nodejs-github-bot]

Review requested:

• @nodejs/performance

[H4ad]

The initial idea was to assert this never returns invalid value due any optimization (such as fast apis)

But this works as well, thanks for the fix

[geeksilva97]

The initial idea was to assert this never returns invalid value due any optimization (such as fast apis)

But this works as well, thanks for the fix

No prob. Btw, this is my first time changing benchmark stuff. Do we need CI for it?

[github-actions]

Benchmark GHA (sqlite / sqlite-is-transaction): https://github.com/nodejs/node/actions/runs/31584406184

Results

[!WARNING]
Do not take GHA benchmark results as face value, always confirm them
using a dedicated machine, e.g. Jenkins CI.

Benchmark results:

 confidence improvement accuracy (*) (**) (***)
sqlite/sqlite-is-transaction.js transaction='false' n=10000000 0.06 % ±2.36% ±3.11% ±3.99%
sqlite/sqlite-is-transaction.js transaction='true' n=10000000 -0.62 % ±2.38% ±3.13% ±4.02%
Be aware that when doing many comparisons the risk of a false-positive
result increases. In this case, there are 2 comparisons, you can thus
expect the following amount of false-positive results:
0.10 false positives, when considering a 5% risk acceptance (*, **, ***),
0.02 false positives, when considering a 1% risk acceptance (**, ***),
0.00 false positives, when considering a 0.1% risk acceptance (***)

[!WARNING]
Do not take GHA benchmark results as face value, always confirm them
using a dedicated machine, e.g. Jenkins CI.

[nodejs-github-bot]

Landed in f914e45

[geeksilva97]

This PR removes the Logical AND assignment. It was causing the benchmark to call the isTransaction only once when the getter was returning false.

With the deadCodeElimination being false, the right side never runs.

Before

$ ./node benchmark/sqlite/sqlite-is-transaction.js
sqlite/sqlite-is-transaction.js transaction="true" n=10000000: 64,634,434.23269218
sqlite/sqlite-is-transaction.js transaction="false" n=10000000: 871,137,051.6366488

After

$ ./node benchmark/sqlite/sqlite-is-transaction.js
sqlite/sqlite-is-transaction.js transaction="true" n=10000000: 64,021,357.52487029
sqlite/sqlite-is-transaction.js transaction="false" n=10000000: 66,274,377.580040805

[nodejs-github-bot]

Review requested:

• @nodejs/performance

[H4ad]

The initial idea was to assert this never returns invalid value due any optimization (such as fast apis)

But this works as well, thanks for the fix

[geeksilva97]

The initial idea was to assert this never returns invalid value due any optimization (such as fast apis)

But this works as well, thanks for the fix

No prob. Btw, this is my first time changing benchmark stuff. Do we need CI for it?

[github-actions]

Benchmark GHA (sqlite / sqlite-is-transaction): https://github.com/nodejs/node/actions/runs/31584406184

Results

[!WARNING]
Do not take GHA benchmark results as face value, always confirm them
using a dedicated machine, e.g. Jenkins CI.

Benchmark results:

 confidence improvement accuracy (*) (**) (***)
sqlite/sqlite-is-transaction.js transaction='false' n=10000000 0.06 % ±2.36% ±3.11% ±3.99%
sqlite/sqlite-is-transaction.js transaction='true' n=10000000 -0.62 % ±2.38% ±3.13% ±4.02%
Be aware that when doing many comparisons the risk of a false-positive
result increases. In this case, there are 2 comparisons, you can thus
expect the following amount of false-positive results:
0.10 false positives, when considering a 5% risk acceptance (*, **, ***),
0.02 false positives, when considering a 1% risk acceptance (**, ***),
0.00 false positives, when considering a 0.1% risk acceptance (***)

[!WARNING]
Do not take GHA benchmark results as face value, always confirm them
using a dedicated machine, e.g. Jenkins CI.

[nodejs-github-bot]

Landed in f914e45

[geeksilva97]

This PR removes the Logical AND assignment. It was causing the benchmark to call the isTransaction only once when the getter was returning false.

With the deadCodeElimination being false, the right side never runs.

Before

$ ./node benchmark/sqlite/sqlite-is-transaction.js
sqlite/sqlite-is-transaction.js transaction="true" n=10000000: 64,634,434.23269218
sqlite/sqlite-is-transaction.js transaction="false" n=10000000: 871,137,051.6366488

After

$ ./node benchmark/sqlite/sqlite-is-transaction.js
sqlite/sqlite-is-transaction.js transaction="true" n=10000000: 64,021,357.52487029
sqlite/sqlite-is-transaction.js transaction="false" n=10000000: 66,274,377.580040805

[nodejs-github-bot]

Review requested:

• @nodejs/performance

[H4ad]

The initial idea was to assert this never returns invalid value due any optimization (such as fast apis)

But this works as well, thanks for the fix

[geeksilva97]

The initial idea was to assert this never returns invalid value due any optimization (such as fast apis)

But this works as well, thanks for the fix

No prob. Btw, this is my first time changing benchmark stuff. Do we need CI for it?

[github-actions]

Benchmark GHA (sqlite / sqlite-is-transaction): https://github.com/nodejs/node/actions/runs/31584406184

Results

[!WARNING]
Do not take GHA benchmark results as face value, always confirm them
using a dedicated machine, e.g. Jenkins CI.

Benchmark results:

 confidence improvement accuracy (*) (**) (***)
sqlite/sqlite-is-transaction.js transaction='false' n=10000000 0.06 % ±2.36% ±3.11% ±3.99%
sqlite/sqlite-is-transaction.js transaction='true' n=10000000 -0.62 % ±2.38% ±3.13% ±4.02%
Be aware that when doing many comparisons the risk of a false-positive
result increases. In this case, there are 2 comparisons, you can thus
expect the following amount of false-positive results:
0.10 false positives, when considering a 5% risk acceptance (*, **, ***),
0.02 false positives, when considering a 1% risk acceptance (**, ***),
0.00 false positives, when considering a 0.1% risk acceptance (***)

[!WARNING]
Do not take GHA benchmark results as face value, always confirm them
using a dedicated machine, e.g. Jenkins CI.

[nodejs-github-bot]

Landed in f914e45

[geeksilva97]

This PR removes the Logical AND assignment. It was causing the benchmark to call the isTransaction only once when the getter was returning false.

With the deadCodeElimination being false, the right side never runs.

Before

$ ./node benchmark/sqlite/sqlite-is-transaction.js
sqlite/sqlite-is-transaction.js transaction="true" n=10000000: 64,634,434.23269218
sqlite/sqlite-is-transaction.js transaction="false" n=10000000: 871,137,051.6366488

After

$ ./node benchmark/sqlite/sqlite-is-transaction.js
sqlite/sqlite-is-transaction.js transaction="true" n=10000000: 64,021,357.52487029
sqlite/sqlite-is-transaction.js transaction="false" n=10000000: 66,274,377.580040805

[nodejs-github-bot]

Review requested:

• @nodejs/performance

[H4ad]

The initial idea was to assert this never returns invalid value due any optimization (such as fast apis)

But this works as well, thanks for the fix

[geeksilva97]

The initial idea was to assert this never returns invalid value due any optimization (such as fast apis)

But this works as well, thanks for the fix

No prob. Btw, this is my first time changing benchmark stuff. Do we need CI for it?

[github-actions]

Benchmark GHA (sqlite / sqlite-is-transaction): https://github.com/nodejs/node/actions/runs/31584406184

Results

[!WARNING]
Do not take GHA benchmark results as face value, always confirm them
using a dedicated machine, e.g. Jenkins CI.

Benchmark results:

 confidence improvement accuracy (*) (**) (***)
sqlite/sqlite-is-transaction.js transaction='false' n=10000000 0.06 % ±2.36% ±3.11% ±3.99%
sqlite/sqlite-is-transaction.js transaction='true' n=10000000 -0.62 % ±2.38% ±3.13% ±4.02%
Be aware that when doing many comparisons the risk of a false-positive
result increases. In this case, there are 2 comparisons, you can thus
expect the following amount of false-positive results:
0.10 false positives, when considering a 5% risk acceptance (*, **, ***),
0.02 false positives, when considering a 1% risk acceptance (**, ***),
0.00 false positives, when considering a 0.1% risk acceptance (***)

[!WARNING]
Do not take GHA benchmark results as face value, always confirm them
using a dedicated machine, e.g. Jenkins CI.

[nodejs-github-bot]

Landed in f914e45

[geeksilva97]

This PR removes the Logical AND assignment. It was causing the benchmark to call the isTransaction only once when the getter was returning false.

With the deadCodeElimination being false, the right side never runs.

Before

$ ./node benchmark/sqlite/sqlite-is-transaction.js
sqlite/sqlite-is-transaction.js transaction="true" n=10000000: 64,634,434.23269218
sqlite/sqlite-is-transaction.js transaction="false" n=10000000: 871,137,051.6366488

After

$ ./node benchmark/sqlite/sqlite-is-transaction.js
sqlite/sqlite-is-transaction.js transaction="true" n=10000000: 64,021,357.52487029
sqlite/sqlite-is-transaction.js transaction="false" n=10000000: 66,274,377.580040805

[nodejs-github-bot]

Review requested:

• @nodejs/performance

[H4ad]

The initial idea was to assert this never returns invalid value due any optimization (such as fast apis)

But this works as well, thanks for the fix

[geeksilva97]

The initial idea was to assert this never returns invalid value due any optimization (such as fast apis)

But this works as well, thanks for the fix

No prob. Btw, this is my first time changing benchmark stuff. Do we need CI for it?

[github-actions]

Benchmark GHA (sqlite / sqlite-is-transaction): https://github.com/nodejs/node/actions/runs/31584406184

Results

[!WARNING]
Do not take GHA benchmark results as face value, always confirm them
using a dedicated machine, e.g. Jenkins CI.

Benchmark results:

 confidence improvement accuracy (*) (**) (***)
sqlite/sqlite-is-transaction.js transaction='false' n=10000000 0.06 % ±2.36% ±3.11% ±3.99%
sqlite/sqlite-is-transaction.js transaction='true' n=10000000 -0.62 % ±2.38% ±3.13% ±4.02%
Be aware that when doing many comparisons the risk of a false-positive
result increases. In this case, there are 2 comparisons, you can thus
expect the following amount of false-positive results:
0.10 false positives, when considering a 5% risk acceptance (*, **, ***),
0.02 false positives, when considering a 1% risk acceptance (**, ***),
0.00 false positives, when considering a 0.1% risk acceptance (***)

[!WARNING]
Do not take GHA benchmark results as face value, always confirm them
using a dedicated machine, e.g. Jenkins CI.

[nodejs-github-bot]

Landed in f914e45

[geeksilva97]

This PR removes the Logical AND assignment. It was causing the benchmark to call the isTransaction only once when the getter was returning false.

With the deadCodeElimination being false, the right side never runs.

Before

$ ./node benchmark/sqlite/sqlite-is-transaction.js
sqlite/sqlite-is-transaction.js transaction="true" n=10000000: 64,634,434.23269218
sqlite/sqlite-is-transaction.js transaction="false" n=10000000: 871,137,051.6366488

After

$ ./node benchmark/sqlite/sqlite-is-transaction.js
sqlite/sqlite-is-transaction.js transaction="true" n=10000000: 64,021,357.52487029
sqlite/sqlite-is-transaction.js transaction="false" n=10000000: 66,274,377.580040805

[nodejs-github-bot]

Review requested:

• @nodejs/performance

[H4ad]

The initial idea was to assert this never returns invalid value due any optimization (such as fast apis)

But this works as well, thanks for the fix

[geeksilva97]

The initial idea was to assert this never returns invalid value due any optimization (such as fast apis)

But this works as well, thanks for the fix

No prob. Btw, this is my first time changing benchmark stuff. Do we need CI for it?

[github-actions]

Benchmark GHA (sqlite / sqlite-is-transaction): https://github.com/nodejs/node/actions/runs/31584406184

Results

[!WARNING]
Do not take GHA benchmark results as face value, always confirm them
using a dedicated machine, e.g. Jenkins CI.

Benchmark results:

 confidence improvement accuracy (*) (**) (***)
sqlite/sqlite-is-transaction.js transaction='false' n=10000000 0.06 % ±2.36% ±3.11% ±3.99%
sqlite/sqlite-is-transaction.js transaction='true' n=10000000 -0.62 % ±2.38% ±3.13% ±4.02%
Be aware that when doing many comparisons the risk of a false-positive
result increases. In this case, there are 2 comparisons, you can thus
expect the following amount of false-positive results:
0.10 false positives, when considering a 5% risk acceptance (*, **, ***),
0.02 false positives, when considering a 1% risk acceptance (**, ***),
0.00 false positives, when considering a 0.1% risk acceptance (***)

[!WARNING]
Do not take GHA benchmark results as face value, always confirm them
using a dedicated machine, e.g. Jenkins CI.

[nodejs-github-bot]

Landed in f914e45

[geeksilva97]

This PR removes the Logical AND assignment. It was causing the benchmark to call the isTransaction only once when the getter was returning false.

With the deadCodeElimination being false, the right side never runs.

Before

$ ./node benchmark/sqlite/sqlite-is-transaction.js
sqlite/sqlite-is-transaction.js transaction="true" n=10000000: 64,634,434.23269218
sqlite/sqlite-is-transaction.js transaction="false" n=10000000: 871,137,051.6366488

After

$ ./node benchmark/sqlite/sqlite-is-transaction.js
sqlite/sqlite-is-transaction.js transaction="true" n=10000000: 64,021,357.52487029
sqlite/sqlite-is-transaction.js transaction="false" n=10000000: 66,274,377.580040805

[nodejs-github-bot]

Review requested:

• @nodejs/performance

[H4ad]

The initial idea was to assert this never returns invalid value due any optimization (such as fast apis)

But this works as well, thanks for the fix

[geeksilva97]

The initial idea was to assert this never returns invalid value due any optimization (such as fast apis)

But this works as well, thanks for the fix

No prob. Btw, this is my first time changing benchmark stuff. Do we need CI for it?

[github-actions]

Benchmark GHA (sqlite / sqlite-is-transaction): https://github.com/nodejs/node/actions/runs/31584406184

Results

[!WARNING]
Do not take GHA benchmark results as face value, always confirm them
using a dedicated machine, e.g. Jenkins CI.

Benchmark results:

 confidence improvement accuracy (*) (**) (***)
sqlite/sqlite-is-transaction.js transaction='false' n=10000000 0.06 % ±2.36% ±3.11% ±3.99%
sqlite/sqlite-is-transaction.js transaction='true' n=10000000 -0.62 % ±2.38% ±3.13% ±4.02%
Be aware that when doing many comparisons the risk of a false-positive
result increases. In this case, there are 2 comparisons, you can thus
expect the following amount of false-positive results:
0.10 false positives, when considering a 5% risk acceptance (*, **, ***),
0.02 false positives, when considering a 1% risk acceptance (**, ***),
0.00 false positives, when considering a 0.1% risk acceptance (***)

[!WARNING]
Do not take GHA benchmark results as face value, always confirm them
using a dedicated machine, e.g. Jenkins CI.

[nodejs-github-bot]

Landed in f914e45