Из реальных проблем для которых ФП структуры данных хорошо помогли — реализация аналога json-path. Правда все готовые реализации ужасно написаны и их невозможно наследовать, особенно плох имбютаблжс и рамда имьютабл, но они в принципе все ужасны (вместо синглтонов используют скрытые подклассы, имьютаблжс вообще кривой, нарушает спецификацию и работает только потому, что предварительно компилится бабелем). И вот это вообще в них бесит const a = Maybe.of({}); // Just({})
const b = a.map(prop('x')); // Just(undefined) - неведомая бесполезная чушь
const c = b.map(prop('y')); // Error
Сделано это в угоду соответствия определениям (u.map(x => f(g(x))) is equivalent to u.map(g).map(f) обе части будут кидать ошибку), но полностью убивает смысл мейби монады которая должна от таких ошибок спасать (хотя можно было ограничить множество функций для которых определение должно работать и все было бы прекрасно). Можно переписать то же через чейн, но это начинает выглядеть плохо и опять же плохо расширяется и наследуется.
Вы не можете передать или вернуть строку в васм, вы можете передать или вернуть только буфер, а буфер можно забрать например из типизированного массива, а он о строках ничего не знает. Так что на стороне жс вы ничего не выиграете и никуда от этого преобразования не денетесь.
Тут даже не в том дело, нужно из строки создать массив значений и потом из массива значений склеить обратно строку. Операции элементарные, но дорогостоящие, особенно склейка. Прийдется преобразовать наборы числовых значений в символы и потом склеить их в одну строку — это обычно нивелирует всю скорость от работы с буфером. Если строковый буфер таки добавят в стандарт — тогда будет нам счастье.
так жс об этом великолепии ничего не знает, как только вы захотите строку из васма достать или в васм впихнуть — быть беде. а дом он в жс так что без этого никуда.
было бы интересно услышать опыт тех, кто этим занимался
Это боль =) Если серьезно, то немного математики туда впихнуть бывает очень удобно, кода получается меньше чем если компилить из с. Но если проект большой, то не вариант. Но в принципе оптимизации асм работают и не в асм режиме, так что можно для математических функций просто сделать аннотацию типов, работать с типизированными массивами вместо обычных и в целом это будет уже как гора с плеч для компилятора.
Всё это то, чего JS не может предоставить компилятору в силу своей парадигмы динамического языка, максимально простого для пользователя
JIT делает предположения и по сути оставляет небольшое поддерево из всего множества вариантов, самое главное не разрушить его ожидания. Да JIT дорогой и время инициализации от этого растет, но не время выполнения. Скажем для игр это не так критично как для магазина одежды.
Ну потому что вам прийдется каждый символ строки превращать в число, потом передавать в васм и там с ним работать и потом возвращать обратно и снова превращать в символ и клеить из этого набора символов большую строку — это уже куча аллокаций. Это дорого, было даже предложение добавить стринг буффер чтоб этого избежать, но пока воз и ныне там. Это проверено экспериментами — игра не стоит свеч. Вообще строки в жс медленные и в парсерах сравнение делается по кикоду, чтоб не сравнивать подстроку с другой строкой и это быстрее.
Эффективнее хранить шаблон в теге шаблона и потом его клонировать и вставлять в дом. А вот дерти-чекинг виртульного дома операция вполне математическая и очень тяжелая, ее теоретически можно скинуть в васм если придумать как tries закодировать в линейную память.
То есть я сравнил асм и васм и сказал, что теперь там таблицы функций более крутые и динамичные, так что с ним можно работать как с длл. В асм тоже так можно было, но там проблема была во внешних функциях которые не аннотировались.
Я и не говорил, что он динамический, я вам говорил про то, что можно к примеру 5 васм модулей между собой переключать и пересвязывать через таблицы этих модулей, по сути это будет схема работы с dll.
Я никогда не спорил с тем, что динамическое определение типов ведет к лишним накладным расходам, но динамическое связывание это все-таки не о том.
Так и жс позволяет избежать этого вида динамичности благодаря развитию JIT.
от dll никуда не убежишь нельзя же все монолитом собирать. Брендон Айк сказал когда-то «Всегда ставьте на джаваскрипт» и пока его голова поднимается все выше, типизация тоже должна появится в каком-то виде, эксперименты с саундскрипт и юз стриктер уже были. Хотя про динамическое связывание было в сторону васм, это у него оно более крутое.
Васм появился скорее потому, что сам жс более многословный и его нужно было ужать во что-то более компактное. Асм был хорош, но очень уж толст и его приходилось долго грузить и парсить, а с типизацией там в принципе все было ок (хотя и не идеально, некоторые проверки оставались)
code/decode между строками и буфером будет довольно дорогим, я думаю они будут там реализовывать иммьютабл деревья для виртуального дома, но пока сложно представить как это будет кодироваться числами в линейной памяти.
Собственно теперешняя реализация васм очень похоже на то, что мы писали на асм если нужно было ускорить часть подсчетов. Разница пока только в инт64, расширяемой линейной памяти и более крутом динамическом связывании через таблицы.
Мы говорим про проверку сложных входных параметров, а дальше можно конечно написать плохой неоптимизируемый код, но как раз математика — это обычно про числа так что можно написать так, что лишних проверок не будет.
indexURLs[user.prefs.languages.primary]
если пользователь есть, но без настроек, а вот это не упадет
Maybe.of(user).map(path('prefs.languages.primary')).getOr(default);
const a = Maybe.of({}); // Just({})
const b = a.map(prop('x')); // Just(undefined) - неведомая бесполезная чушь
const c = b.map(prop('y')); // Error
Сделано это в угоду соответствия определениям (u.map(x => f(g(x))) is equivalent to u.map(g).map(f) обе части будут кидать ошибку), но полностью убивает смысл мейби монады которая должна от таких ошибок спасать (хотя можно было ограничить множество функций для которых определение должно работать и все было бы прекрасно). Можно переписать то же через чейн, но это начинает выглядеть плохо и опять же плохо расширяется и наследуется.
Бенчмарчили уже — все плохо. При склейке происходят множественные аллокации для создания большой строки из символов.
Это боль =) Если серьезно, то немного математики туда впихнуть бывает очень удобно, кода получается меньше чем если компилить из с. Но если проект большой, то не вариант. Но в принципе оптимизации асм работают и не в асм режиме, так что можно для математических функций просто сделать аннотацию типов, работать с типизированными массивами вместо обычных и в целом это будет уже как гора с плеч для компилятора.
JIT делает предположения и по сути оставляет небольшое поддерево из всего множества вариантов, самое главное не разрушить его ожидания. Да JIT дорогой и время инициализации от этого растет, но не время выполнения. Скажем для игр это не так критично как для магазина одежды.
Эффективнее хранить шаблон в теге шаблона и потом его клонировать и вставлять в дом. А вот дерти-чекинг виртульного дома операция вполне математическая и очень тяжелая, ее теоретически можно скинуть в васм если придумать как tries закодировать в линейную память.
Я никогда не спорил с тем, что динамическое определение типов ведет к лишним накладным расходам, но динамическое связывание это все-таки не о том.
Так и жс позволяет избежать этого вида динамичности благодаря развитию JIT.
Васм появился скорее потому, что сам жс более многословный и его нужно было ужать во что-то более компактное. Асм был хорош, но очень уж толст и его приходилось долго грузить и парсить, а с типизацией там в принципе все было ок (хотя и не идеально, некоторые проверки оставались)