1
0
Fork 0
mirror of https://github.com/denoland/deno.git synced 2024-12-22 23:34:47 -05:00
Commit graph

10 commits

Author SHA1 Message Date
Matt Mastracci
bb1f5e4262
perf(core): async op pseudo-codegen and performance work (#18887)
Performance:

```
async_ops.js: 760k -> 1030k (!)
async_ops_deferred.js: 730k -> 770k
Deno.serve bench: 118k -> 124k
WS test w/ third_party/prebuilt/mac/load_test 100 localhost 8000 0 0: unchanged

Startup time: approx 0.5ms slower (13.7 -> 14.2ms)
```
2023-04-30 08:50:24 +00:00
Divy Srivastava
b9a3790932
perf: const op declaration (#18288)
Co-authored-by: Levente Kurusa <lkurusa@kernelstuff.org>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
2023-03-31 14:42:14 +02:00
Divy Srivastava
b2fd0742bd
feat: port node:zlib to rust (#18291) 2023-03-27 16:03:07 +00:00
Bartek Iwańczuk
3c9771deb2
Reland "perf(core): preserve ops between snapshots (#18080)" (#18272)
Relanding 4b6305f4f2
2023-03-18 18:30:04 -04:00
Bartek Iwańczuk
d11e89127d
Revert "perf(core): preserve ops between snapshots (#18080)" (#18267)
This reverts commit 4b6305f4f2.
2023-03-18 14:59:51 +00:00
Bartek Iwańczuk
4b6305f4f2
perf(core): preserve ops between snapshots (#18080)
This commit changes the build process in a way that preserves already
registered ops in the snapshot. This allows us to skip creating hundreds of
"v8::String" on each startup, but sadly there is still some op registration
going on startup (however we're registering 49 ops instead of >200 ops). 

This situation could be further improved, by moving some of the ops 
from "runtime/" to a separate extension crates.

---------

Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
2023-03-18 12:51:21 +01:00
Divy Srivastava
eb3d79ab1b
chore(ops): inline FastFunction trait methods (#18226) 2023-03-16 13:20:41 +00:00
Divy Srivastava
d4807f458e
chore(core): remove argc field from OpDecl (#18024)
https://github.com/denoland/deno/pull/18023#discussion_r1125611859
2023-03-05 11:16:43 +00:00
Aapo Alasuutari
04ba709b6e
perf(ops): Remove unnecessary fast call fallback options usage (#17585)
Currently fast ops will always check for the alignment of a TypedArray
when getting a slice out of them. A match is then done to ensure that
some slice was received and if not a fallback will be requested.

For Uint8Arrays (and WasmMemory which is equivalent to a Uint8Array) the
alignment will always be okay. Rust probably optimises this away for the
most part (since the Uint8Array check is `x % 1 != 0`), but what it
cannot optimise away is the fast ops path's request for fallback options
parameter.

The extra parameter's cost is likely negligible but V8 will need to
check if a fallback was requested and prepare the fallback call just in
case it was. In the future the lack of a fallback may also enable V8 to
much better optimise the result handling.

For V8 created buffers, it seems like all buffers are actually always
guaranteed to be properly aligned: All buffers seem to always be created
8-byte aligned, and creating a 32 bit array or 64 bit array with a
non-aligned offset from an ArrayBuffer is not allowed. Unfortunately,
Deno FFI cannot give the same guarantees, and it is actually possible
for eg. 32 bit arrays to be created unaligned using it. These arrays
work fine (at least on Linux) so it seems like this is not illegal, it
just means that we cannot remove the alignment checking for 32 bit
arrays.
2023-01-29 19:35:08 +05:30
Divy Srivastava
9ffc6acdbb
perf(ops): Reenable fast unit result optimization (#16827)
The optimization was missed in the optimizer rewrite
https://github.com/denoland/deno/pull/16514
2022-11-27 04:48:17 +00:00