может экспортированные? Для этого достаточно использовать loader и метод wrap:
https://www.assemblyscript.org/loader.html#custom-classes

извиняюсь, да именно экспортированые.
есть вот такие два класса.

export class OptionalFloat64Value {
  public value: f64;
  public isEmpty: bool;

  constructor(value: f64, isEmpty: bool) {
    this.value = value;
    this.isEmpty = isEmpty;
  }
}

export class ChartPoint {
  index: f64;
  millis: f64;
  balance: OptionalFloat64Value;
  equity: OptionalFloat64Value;
  isLoop: bool;

  constructor(
    index: f64,
    millis: f64,
    balance: OptionalFloat64Value,
    equity: OptionalFloat64Value,
    isLoop: bool
  ) {
    this.index = index;
    this.millis = millis;
    this.balance = balance;
    this.equity = equity;
    this.isLoop = isLoop;
  }
}

использую .wrap но очень медленно все. но почему то реализация на AS в 7-10 раз медленнее реализации на JS
https://github.com/olegshilov/wasm-experiments

дебажу и вижу что оч медленно работает как раз wrap

Если честно я не увидет где там хоть какие то сложные вычисления. Никаких циклов или математических функций. Все съедает интероп между js и wasm
https://github.com/olegshilov/wasm-experiments/blob/master/assembly/index.ts

WebAssembly очень похож в этом смысле на GPU. Если его как следует не загрузить вычислениями при этом минифицировав общение между wasm модулем и хостом, то никаких преимуществ в производительности не получиться

понял. попробую именно сам reduce туда унести.
потому что сейчас задача стоит в том что веб очень медленно редьюсит данные, и этот момент  надо ускорить.
но я предвижу проблему в том что обьекты которые в массиве имеют null | undefined а я хз как их хендлить в AS.

SomeReference | null поддерживается в AS. Примитивные типы вроде i32 | null пока что нет, но их можно завернуть в класс (boxing) например.

> сейчас задача стоит в том что веб очень медленно редьюсит данные

Обычно это не очень хорошая задача для WebAssembly, но можно конечно попробовать добиться небольшого прироста. Намного больше вы добъетесь распаралелив через веб воркеры

мы уже из воркера это пытаемся вынести.

> Обычно это не очень хорошая задача для WebAssembly
возник вопрос, а что тогда является хорошей задачей для WebAssembly?

Более комплексные высокоинтенсивные задачи:
- обработка изображений (хотя даже здесь не все однозначно)
- сложные математические операции (pow, exp, sin, cos), физические движки и симуляции
- криптография (особенно там где нужны 64-битные числа)
- сложные алгоритмические задачи над большими выборками данных
- кодирока / декодировка бинартых или текстовых данных, парсинг
- machine learning

ну и т д в том же духе

Спасибо

Ну вот в Blazor уже и Full AOT режим подвезли, а он все равно не может обогнать JS на элементарнейшем бенчмарке:
https://blazor-check.web.app

upd: автор изменил бенчмарк

У меня сшарп быстрее:

74-80мс - шарпы
287-290 - жс

Тот же бенчмарк на AS/JS
https://bit.ly/3gJFYXR

Chrome:
js: 108.29999995231628 ms
as: 23.5 ms

Это мобильный хром

Попробуй на десктопном

У меня

Chrome 91:
JS: 107 ms
Blazor: 130 ms

FF 89:
JS: 109 ms
Blazor: 261 ms

на мобильном
174 c#
608 js

еще попробывал , в среднем :
208 c#
265 js