1
0
Fork 0
mirror of https://github.com/denoland/deno.git synced 2024-11-22 15:06:54 -05:00
Commit graph

10 commits

Author SHA1 Message Date
Luca Casonato
7495bcbf77
Revert "perf(ext/node): improve Buffer from string performance" (#24851) 2024-08-02 16:23:21 +02:00
Divy Srivastava
1ba88a7892
perf(ext/node): improve Buffer from string performance (#24567)
Fixes https://github.com/denoland/deno/issues/24323

- Use a Buffer pool for `fromString`
- Implement fast call base64 writes
- Direct from string `create` method for each encoding op

```
$ deno bench -A bench.mjs # 1.45.1+fee4d3a
cpu: Apple M1 Pro
runtime: deno 1.45.1+fee4d3a (aarch64-apple-darwin)

benchmark                time (avg)             (min … max)       p75       p99      p999
----------------------------------------------------------- -----------------------------
Buffer.from base64      550 ns/iter     (490 ns … 1'265 ns)    572 ns    606 ns  1'265 ns
Buffer#write base64     285 ns/iter       (259 ns … 371 ns)    307 ns    347 ns    360 ns

$ ~/gh/deno/target/release/deno bench -A bench.mjs # this PR
cpu: Apple M1 Pro
runtime: deno dev (aarch64-apple-darwin)

benchmark                time (avg)             (min … max)       p75       p99      p999
----------------------------------------------------------- -----------------------------
Buffer.from base64      151 ns/iter       (145 ns … 770 ns)    148 ns    184 ns    648 ns
Buffer#write base64   62.58 ns/iter     (60.79 ns … 157 ns)  61.65 ns  75.79 ns    141 ns

$ node bench.mjs # v22.4.0
cpu: Apple M1 Pro
runtime: node v22.4.0 (arm64-darwin)

benchmark                time (avg)             (min … max)       p75       p99      p999
----------------------------------------------------------- -----------------------------
Buffer.from base64      163 ns/iter     (96.92 ns … 375 ns)  99.45 ns    127 ns    220 ns
Buffer#write base64   75.48 ns/iter     (74.97 ns … 134 ns)  75.17 ns  81.83 ns  96.84 ns
```
2024-07-30 18:09:55 +05:30
Asher Gomez
9168078669
fix(ext/node): use primordials in ext/node/polyfills/string_decoder.ts (#24296) 2024-06-21 15:52:20 +10:00
Nathan Whitaker
ebbc897b69
fix(ext/node): Reimplement StringDecoder to match node's behavior (#22933)
Fixes #22158.

Basically reimplements the whole `StringDecoder` with a much more direct
translation (read like one-to-one) of node's current logic. The old
implementation was closer to node's super old impl and it was too hard
to keep the code structure while matching the behavior of their new
logic.

This adds support for UTF-16LE, ascii, and latin1. 

This also enables the node_compat test, which now passes without
modification.
2024-03-15 17:24:13 -07:00
David Sherret
7e72f3af61
chore: update copyright to 2024 (#21753) 2024-01-01 19:58:21 +00:00
Bartek Iwańczuk
01f0d03ae8
refactor: rename built-in node modules from ext:deno_node/ to node: (#19680)
Closes https://github.com/denoland/deno/issues/19510
2023-07-02 20:19:30 +02:00
Kenta Moriuchi
e16b74d792
chore(ext/node): disable prefer-primordials on a per-file basis (#19553) 2023-06-27 15:18:22 +09:00
Bartek Iwańczuk
72fe9bb470
refactor: rename InternalModuleLoader to ExtModuleLoader, use ext: scheme for snapshotted modules (#18041)
This commit renames "deno_core::InternalModuleLoader" to
"ExtModuleLoader" and changes the specifiers used by the 
modules loaded from this loader to "ext:".

"internal:" scheme was really ambiguous and it's more characters than
"ext:", which should result in slightly smaller snapshot size.

Closes https://github.com/denoland/deno/issues/18020
2023-03-08 12:44:54 +01:00
Bartek Iwańczuk
b40086fd7d
refactor(core): include_js_files! 'dir' option doesn't change specifiers (#18019)
This commit changes "include_js_files!" macro from "deno_core"
in a way that "dir" option doesn't cause specifiers to be rewritten 
to include it.

Example:
```
include_js_files! {
  dir "js",
  "hello.js",
}
```

The above definition required embedders to use:
`import ... from "internal:<ext_name>/js/hello.js"`. 
But with this change, the "js" directory in which the files are stored
is an implementation detail, which for embedders results in: 
`import ... from "internal:<ext_name>/hello.js"`.

The directory the files are stored in, is an implementation detail and 
in some cases might result in a significant size difference for the 
snapshot. As an example, in "deno_node" extension, we store the 
source code in "polyfills" directory; which resulted in each specifier 
to look like "internal:deno_node/polyfills/<module_name>", but with 
this change it's "internal:deno_node/<module_name>". 

Given that "deno_node" has over 100 files, many of them having 
several import specifiers to the same extension, this change removes
10 characters from each import specifier.
2023-03-05 02:31:38 +00:00
Bartek Iwańczuk
d47147fb6a
feat(ext/node): embed std/node into the snapshot (#17724)
This commit moves "deno_std/node" in "ext/node" crate. The code is
transpiled and snapshotted during the build process.

During the first pass a minimal amount of work was done to create the
snapshot, a lot of code in "ext/node" depends on presence of "Deno"
global. This code will be gradually fixed in the follow up PRs to migrate
it to import relevant APIs from "internal:" modules.

Currently the code from snapshot is not used in any way, and all
Node/npm compatibility still uses code from 
"https://deno.land/std/node" (or from the location specified by 
"DENO_NODE_COMPAT_URL"). This will also be handled in a follow 
up PRs.

---------

Co-authored-by: crowlkats <crowlkats@toaxl.com>
Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
Co-authored-by: Yoshiya Hinosawa <stibium121@gmail.com>
2023-02-14 17:38:45 +01:00