You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+59-3Lines changed: 59 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -121,13 +121,69 @@ Please see the [AssemblyScript Docs on runtime variants](https://docs.assemblysc
121
121
122
122
## Performance
123
123
124
-
TODO
124
+
as-bind does all of it's data passing at runtime. Meaning this will be slower than a code generated bindings generator, such as something like [wasm-bindgen](https://github.com/rustwasm/wasm-bindgen). This is because, as-bind needs to cycle through every supported type on every paremeter or return value for each function, whenever the function is called. However, this is mitigated due to the Speculative execution that the library implements. Which. in this case it means, that the library by default will assume the type of value being passed to, or returned by a function will not change, and will only have to cycle through the params once, and then after that, it would be as fast as a code generated solution (in theory). This speculative execution can be turned off as specified in the Reference API.
125
+
126
+
If your project is doing one-off processing using a high level data type, this project should have a very small impact on performance of your project. However, if you project is doing it's processing in a very time constrained loop (such as a game running at 60fps), you may want to be more considerate when choosing this library. The speculative execution should greatly help in the amount of time to pass high level data types, but if your game is already not running as fast as you would like, you may want to avoid this library, or even not using high level data types, for passing memory to your WebAssembly module.
127
+
128
+
Eventually for the most performant option, we would want to do some JavaScript code generation in the AssemblyScript compiler itself, as part of an `as-bindgen` project for the most performant data passing.
129
+
130
+
**TL;DR** This library should be fast, but depending on your project you may want some more careful consideration.
125
131
126
132
## Reference API
127
133
128
-
TODO
134
+
### AsBind
135
+
136
+
The default exported ESM class of `as-bind`, also available as `import { AsBind } from "as-bind"` / `const { AsBind } = require('as-bind')`.
137
+
138
+
#### Class Properties
139
+
140
+
The `AsBind` class is meant to vaugely act as the [WebAssembly](https://developer.mozilla.org/en-US/docs/WebAssembly) Object exposed to JavaScript environments.
141
+
142
+
##### version
143
+
144
+
`AsBind.version: string`
145
+
146
+
Value that is the current version of your imported AsBind.
147
+
148
+
##### instantiate
149
+
150
+
```typescript
151
+
AsBind.instantiate: (
152
+
moduleOrBuffer: (
153
+
WebAssembly.Module|
154
+
BufferSource|
155
+
Response|
156
+
PromiseLike<WebAssembly.Module|
157
+
BufferSource|
158
+
Response
159
+
),
160
+
imports?:WasmImports
161
+
) =>Promise<AsBindInstance>`
162
+
```
163
+
164
+
Thisfunction is the equivalent to the [AssemblyScript Loader instantiate](https://github.com/AssemblyScript/assemblyscript/tree/master/lib/loader#api) function, which is similar to the [WebAssembly.instantiateStreaming](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_objects/WebAssembly/instantiateStreaming) function. It essentially takes as it's parameters:
- A [WebAssemblyimportObject](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_objects/WebAssembly/instantiateStreaming), which would have all of your imported functions that can be called from within your AssemblyScript module.
0 commit comments