summaryrefslogtreecommitdiff
path: root/ext/node/polyfills/string_decoder.ts
AgeCommit message (Collapse)Author
2024-09-06fix(runtime): use more null proto objects again (#25040)Kenta Moriuchi
proceed with #23921 This PR is a preparation for https://github.com/denoland/deno_lint/pull/1307 --------- Signed-off-by: Kenta Moriuchi <moriken@kimamass.com> Co-authored-by: Luca Casonato <hello@lcas.dev>
2024-08-02Revert "perf(ext/node): improve `Buffer` from string performance" (#24851)Luca Casonato
2024-07-30perf(ext/node): improve `Buffer` from string performance (#24567)Divy Srivastava
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-06-21fix(ext/node): use primordials in `ext/node/polyfills/string_decoder.ts` ↵Asher Gomez
(#24296)
2024-03-15fix(ext/node): Reimplement StringDecoder to match node's behavior (#22933)Nathan Whitaker
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-01-01chore: update copyright to 2024 (#21753)David Sherret
2023-07-02refactor: rename built-in node modules from ext:deno_node/ to node: (#19680)Bartek Iwańczuk
Closes https://github.com/denoland/deno/issues/19510
2023-06-27chore(ext/node): disable prefer-primordials on a per-file basis (#19553)Kenta Moriuchi
2023-03-08refactor: rename InternalModuleLoader to ExtModuleLoader, use ext: scheme ↵Bartek Iwańczuk
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-05refactor(core): include_js_files! 'dir' option doesn't change specifiers ↵Bartek Iwańczuk
(#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-02-14feat(ext/node): embed std/node into the snapshot (#17724)Bartek Iwańczuk
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>