perf: optimization of request instantiation

[tsctx]

1. Reuse fetch optimization logic in core.
2. Avoid lowercasing.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 98.21429% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 94.16%. Comparing base (ad9b5bd) to head (4cf7be2).

Files	Patch %	Lines
lib/web/fetch/util.js	50.00%	1 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3107      +/-   ##
==========================================
- Coverage   94.17%   94.16%   -0.02%     
==========================================
  Files          90       90              
  Lines       24320    24320              
==========================================
- Hits        22904    22901       -3     
- Misses       1416     1419       +3     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[tsctx]

Is there a reason to combine method validation and normalization into a single method?

The reason for wanting to normalize and verify at the same time is that the case used in the verification can be reused.

This instantly breaks the second we need one and not the other.

Yes, it is. The function was not changed, but a new one was created.

[tsctx]

Can you share the bench results?

import Request from "../../lib/core/request.js";
import DecoratorHandler from "../../lib/handler/decorator-handler.js";

import { bench, group, run } from 'mitata'

const handler = new DecoratorHandler({})

bench('new Request()', () => {
    return new Request('https://localhost', { path: "/", method: "get", body: null }, handler);
})

await run()

• main

benchmark          time (avg)             (min … max)       p75       p99      p999
----------------------------------------------------- -----------------------------
new Request()     114 ns/iter   (89.75 ns … 2'124 ns)    124 ns    256 ns  1'619 ns```

• this patch

benchmark          time (avg)             (min … max)       p75       p99      p999
----------------------------------------------------- -----------------------------
new Request()   90.41 ns/iter   (70.85 ns … 1'729 ns)    106 ns    205 ns    717 ns

[Uzlopak]

Thank you for the benchmark. Can you add it to the benchmark folder please?

[luanmuniz]

This is just a comment from someone who doesn't know how this repo works, so feel free to ignore it:

I see optimization, and I just want to say that I found Map() to be more performant than plain objects. It could be a slight performance improvement to have normalizedMethodRecordsBase as Map() instead of a plain object.