Skip to content

Commit 3bdd000

Browse files
authored
Initial
1 parent ae19946 commit 3bdd000

File tree

1 file changed

+70
-37
lines changed

1 file changed

+70
-37
lines changed

README.md

Lines changed: 70 additions & 37 deletions
Original file line numberDiff line numberDiff line change
@@ -1,50 +1,83 @@
1-
# template-for-proposals
1+
# TypedArray Concatenation
22

3-
A repository template for ECMAScript proposals.
3+
ECMAScript Proposal for TypedArray concatentation
44

5-
## Before creating a proposal
5+
This proposal is currently [stage 1](https://github.com/tc39/proposals/blob/master/README.md) of the [process](https://tc39.github.io/process-document/).
66

7-
Please ensure the following:
8-
1. You have read the [process document](https://tc39.github.io/process-document/)
9-
1. You have reviewed the [existing proposals](https://github.com/tc39/proposals/)
10-
1. You are aware that your proposal requires being a member of TC39, or locating a TC39 delegate to “champion” your proposal
7+
## Problem
118

12-
## Create your proposal repo
9+
ECMAScript should provide a native method for concatenating TypedArrays that enables implementations to optimize through strategies that can avoid the current requirement of eagerly allocating and copying data into new buffers
1310

14-
Follow these steps:
15-
1. Click the green [“use this template”](https://github.com/tc39/template-for-proposals/generate) button in the repo header. (Note: Do not fork this repo in GitHub's web interface, as that will later prevent transfer into the TC39 organization)
16-
1. Update ecmarkup and the biblio to the latest version: `npm install --save-dev ecmarkup@latest && npm install --save-dev --save-exact @tc39/ecma262-biblio@latest`.
17-
1. Go to your repo settings page:
18-
1. Under “General”, under “Features”, ensure “Issues” is checked, and disable “Wiki”, and “Projects” (unless you intend to use Projects)
19-
1. Under “Pull Requests”, check “Always suggest updating pull request branches” and “automatically delete head branches”
20-
1. Under the “Pages” section on the left sidebar, and set the source to “deploy from a branch”, select “gh-pages” in the branch dropdown, and then ensure that “Enforce HTTPS” is checked.
21-
1. Under the “Actions” section on the left sidebar, under “General”, select “Read and write permissions” under “Workflow permissions” and click “Save”
22-
1. [“How to write a good explainer”][explainer] explains how to make a good first impression.
11+
It is common for applications on the web (both browser and server side) to need to concatenate two or more TypedArray instances as part of a data pipeline. Unfortunately, the mechanisms available for concatenation are difficult to optimize for performance. All require additional allocations and copying at inopportune times in the application.
2312

24-
> Each TC39 proposal should have a `README.md` file which explains the purpose
25-
> of the proposal and its shape at a high level.
26-
>
27-
> ...
28-
>
29-
> The rest of this page can be used as a template ...
13+
A common example is a `WritableStream` instance that collects writes up to a defined threshold before passing those on in a single coalesced chunk. Server-side applications have typically relied on Node.js' `Buffer.concat` API, while browser applications have relied on either browser-compatible polyfills of `Buffer` or `TypedArray.prototype.set`.
3014

31-
Your explainer can point readers to the `index.html` generated from `spec.emu`
32-
via markdown like
15+
```js
16+
let buffers = [];
17+
let size = 0;
18+
new WritableStream({
19+
write(chunk) {
20+
buffers.push(chunk);
21+
size += chunks.length;
22+
if (buffer.byteLength >= 4096) {
23+
// Not yet the actual proposed syntax... we have to determine that still
24+
flushBuffer(concat(buffers, size));
25+
buffers = [];
26+
size = 0;
27+
}
28+
}
29+
});
3330

34-
```markdown
35-
You can browse the [ecmarkup output](https://ACCOUNT.github.io/PROJECT/)
36-
or browse the [source](https://github.com/ACCOUNT/PROJECT/blob/HEAD/spec.emu).
37-
```
31+
function concat(buffers, size) {
32+
const dest = new Uint8Array(size);
33+
let offset = 0;
34+
for (const buffer of buffers) {
35+
dest.set(buffer, offset);
36+
offset += buffer.length;
37+
}
38+
}
39+
```
3840

39-
where *ACCOUNT* and *PROJECT* are the first two path elements in your project's Github URL.
40-
For example, for github.com/**tc39**/**template-for-proposals**, *ACCOUNT* is “tc39”
41-
and *PROJECT* is “template-for-proposals”.
41+
```js
42+
const buffer1 = Buffer.from('hello');
43+
const buffer2 = Buffer.from('world');
44+
const buffer3 = Buffer.concat([buffer1, buffer2]);
45+
```
4246

47+
While these approaches work, they end up being difficult to optimize because they require potential expensive allocations and data copying at inopportune times while processing the information. The `TypedArray.prototype.set` method does provide an approach for concatenation that is workable, but the way the algorithm is defined, there is no allowance given for implementation-defined optimization.
4348

44-
## Maintain your proposal repo
49+
## Proposal
4550

46-
1. Make your changes to `spec.emu` (ecmarkup uses HTML syntax, but is not HTML, so I strongly suggest not naming it “.html”)
47-
1. Any commit that makes meaningful changes to the spec, should run `npm run build` to verify that the build will succeed and the output looks as expected.
48-
1. Whenever you update `ecmarkup`, run `npm run build` to verify that the build will succeed and the output looks as expected.
51+
This proposal seeks to improve the current state by providing a mechanism that provides an optimizable concatenation path for TypedArrays within the language.
4952

50-
[explainer]: https://github.com/tc39/how-we-work/blob/HEAD/explainer.md
53+
As a stage 1 proposal, the exact mechanism has yet to be defined but the goal would be to achieve a model very similar to Node.js' `Buffer.concat`, where multiple input `TypedArray`s can be given and the implementation can determine the most optimum approach to concatenating those into a single returned `TypedArray` of the same type.
54+
55+
```js
56+
const enc = new TextEncoder();
57+
const u8_1 = enc.encode('Hello ');
58+
const u8_2 = enc.encode('World!');
59+
const u8_3 = Uint8Array.concat([u8_1, u8_2]);
60+
```
61+
62+
A key goal, if a reasonable approach to do so is found, would be to afford implementations the ability to determine the most optimal approach, and optimal timing, for performing the allocations and copies, but no specific optimization would be required.
63+
64+
### Differences from `set`
65+
66+
Per the current definition of `TypedArray.prototype.set` in the language specification, the user code is responsible for allocating the destination `TypedArray` in advance along with calculating and updating the offset at which each copied segment should go. Allocations can be expensive and the book keeping can be cumbersome, particularly when the are multiple input `TypedArrays`. The `set` algorithm is also written such that each element of the copied `TypedArray` is copied to the destination one element at a time, with no affordance given to allow the implementation to determine an alternative, more optimal copy strategy.
67+
68+
```js
69+
let buffers = [];
70+
let size = 0;
71+
new WritableStream({
72+
write(chunk) {
73+
buffers.push(chunk);
74+
size += chunks.length;
75+
if (size >= 4096) {
76+
// Not yet the actual proposed syntax... we have to determine that still
77+
flushBuffer(Uint8Array.concat(buffers, size));
78+
buffers = [];
79+
size = 0;
80+
}
81+
}
82+
});
83+
```

0 commit comments

Comments
 (0)