кто использует knex либо обычные sql запросы без orm, используете ли какие либо удобные тулзы, для мэппинга ответов от запросов с джоинами 1:M M:M?

Objection.Js

Objection.Js

+1

Objection.Js

Это же orm?

Почти

Кажется, он значительно медленнее и так не реактивного Express. Нет? Или вам скорость не решает?

Ну во-первых, для меня пока скорость не критична, а во-вторых, хотелось бы посмотреть источник такой информации :)

Никто не мешает писать raw

Ну и маппинг 1:1, 1:n, n:n есть

Ну такой маппинг во всех орм есть же

он еще и в nginx отлично работает, особенно любят такой подход китайские парни

ну вот есть прекрасный luajit. вот тарантул если нужна скорость то логику в тарантуле и впереди на go какие-нибудь штуки для трафика

Ну во-первых, для меня пока скорость не критична, а во-вторых, хотелось бы посмотреть источник такой информации :)

ну я смотрел несколько бенчмарков, верить бенчмаркам сложно, автор всегда побеждает со своим модулем.

ну я смотрел несколько бенчмарков, верить бенчмаркам сложно, автор всегда побеждает со своим модулем.

Да, вот сам нашёл бенчмарк свежий — https://raygun.com/blog/node-js-performance-2017/

Действительно, сильно проигрывает

ну вот есть прекрасный luajit. вот тарантул если нужна скорость то логику в тарантуле и впереди на go какие-нибудь штуки для трафика

ну я так понимаю смысл основной luajt в таких местах это расширение логики работы "не отходя от кассы", поэтому оно вам либо нужно, либо не нужно. никто же не навязывает такой подход.

Кстати народ, какой сервис сносно и бесплатно может перевести дохуищю текста на самых разных языках на инглишь?

https://translate.google.ru/

Он платный

Я про промышленное использование. Так то да, заплатил и не паришься. Ищу именно фор фри пусть и в ущерб качеству

Ну если тебе надо переводить 12 Гбит/сек, то только платно))

Ну нет, в общем он сейчас используется в проекте и это самая большая статья расходов

Быстро, много, бесплатно — выберите любые два

Можно медленно)

а кто-нибудь озадачивался вопросом быстрейшего парсинга JSON на NodeJs? есть ли что-то значительно быстрее JSON.parse?

Я полюбил Коа, кастомизируемый очень сильно и это очень нравится

а кто-нибудь озадачивался вопросом быстрейшего парсинга JSON на NodeJs? есть ли что-то значительно быстрее JSON.parse?

Потоковые парсеры в npm видел. Хотел заюзать, но не пригодилось

а кто-нибудь озадачивался вопросом быстрейшего парсинга JSON на NodeJs? есть ли что-то значительно быстрее JSON.parse?

Нет и быть не может

Нет и быть не может

почему не может?

а что упираетесь в JSON parse? Вроде один из самых быстрых парсингов такого нетипизированного формата

а кто-нибудь озадачивался вопросом быстрейшего парсинга JSON на NodeJs? есть ли что-то значительно быстрее JSON.parse?

Смотря что именно ты имеешь в виду под парсингом. Если string -> json в общем виде, то скорее всего JSON.parse твой выбор. Ну... может быть какая-то нативщина существует, которая будет быстрее, но интеграция падает на твои плечи. Потоковые парсеры на ноде вообще очень странно-сложная штука. Возможен вариант, когда ты, например реально не хочешь парсить всё, а хочешь получить данные только из некоего подмножества. В таком случае таки да, тебе нужен SAX парсер. И в определенных случаях даже плохонький SAX будет быстрее чем JSON.parse

а что упираетесь в JSON parse? Вроде один из самых быстрых парсингов такого нетипизированного формата

не то чтобы упираюсь прям сейчас, но потенциально это адский ботлнек для критичных ко времени операций.

не то чтобы упираюсь прям сейчас, но потенциально это адский ботлнек для критичных ко времени операций.

а чего парсите-то?

а чего парсите-то?

JSON в несколько КБ размером

Тогда и не парься

SAX/потоковый парсер на таких объемах тебе даст большой оверхед. Он вообще для другого. А если ты напишешь более быстрый JSON.parse, то срочно публикуй в npm )

Тогда и не парься

ну на больших нагрузках это приводит к большим проблемам которые там на месте с наскока уже не решить)

Это решается простой балансировкой

SAX/потоковый парсер на таких объемах тебе даст большой оверхед. Он вообще для другого. А если ты напишешь более быстрый JSON.parse, то срочно публикуй в npm )

ну зачем я? есть десятки сишных и кто-то даже говорит что быстрее протобуфа умеет, и к ним даже есть обвязки к ноде

Ну смотри, JSON.parse в данном случае - чистое вычисление. Т.е. в рамках ноды ты его не сможешь ни распараллелить, ни пустить хм.. в другой поток Учитывая, что я напрочь не знаю, как устроен внутри JSON.parse, но знаю как устроены парсеры JSON в некоторых других языках, то мой опыт говорит, что едва ли ты напишешь что-то чуть более быстрое, чем JSON.parse. По крайней мере это не решит твою проблему с нагрузкой.

Это решается простой балансировкой

балансировкой чего именно?

Всего приложения

нагрузки по инстансам приложения

В общем Vladimir прав. Думаю про балансировку и scale-out

нагрузки по инстансам приложения

ну оптимизация скорости парсера - вопрос вертикального масштабирования, а инстансы и распределение - это горизонтальное. разные области

Это так, но скорость парсинга не должна быть существенной для масштабирования

Ну тут идея такая, что ты не получишь 200% ускорения на парсере

Если она существенно - то это фундаментальные проблемы

Ну смотри, JSON.parse в данном случае - чистое вычисление. Т.е. в рамках ноды ты его не сможешь ни распараллелить, ни пустить хм.. в другой поток Учитывая, что я напрочь не знаю, как устроен внутри JSON.parse, но знаю как устроены парсеры JSON в некоторых других языках, то мой опыт говорит, что едва ли ты напишешь что-то чуть более быстрое, чем JSON.parse. По крайней мере это не решит твою проблему с нагрузкой.

да, тут возможный вариант использовать стороннюю либу с обвязкой только

Никакая либа не даст тебе тот же интерфейс что JSON.parse быстрее

да, тут возможный вариант использовать стороннюю либу с обвязкой только

не забывай про всякие радости в духе копировние данных, переключение контекстов и всё это добро. Потому что данные, которые ты собрал в C еще надо в виртуальную машину подпихнуть

Никакая либа не даст тебе тот же интерфейс что JSON.parse быстрее

почему? если сам парсинг реализован намного быстрее в сторонней либе, то почему не даст?

Потому что он сам парсинг занимает незначительную часть времени

не забывай про всякие радости в духе копировние данных, переключение контекстов и всё это добро. Потому что данные, которые ты собрал в C еще надо в виртуальную машину подпихнуть

да, эти накладные расходы неизбежны

Я экспериментировал с подобным подходом

Результат - только потеря производительности

Результат - только потеря производительности

а можно конкретнее? что с чем сравнивали?

например в го есть реализации работающие с json в 10 (!) раз быстрее чем стандартная библиотека, поэтому непонятно почему стандартная бибилотека эталон? тем более глядя на нативную реализацию в ноде промисов эпичную, которая нереально плоха была до недавнего времени

не забывай про всякие радости в духе копировние данных, переключение контекстов и всё это добро. Потому что данные, которые ты собрал в C еще надо в виртуальную машину подпихнуть

тут на самом деле все не так страшно, поток один и переключений контекста не будет, основная задача это аллоцировать данные из v8 в js-объект

тут на самом деле все не так страшно, поток один и переключений контекста не будет, основная задача это аллоцировать данные из v8 в js-объект

ну тут хз, потому что в вопросах интеграции с нативщиной я только с JVM страдал)

а можно конкретнее? что с чем сравнивали?

c JSON.stringify

При этом парсер работал в параллельном потоке

При этом парсер работал в параллельном потоке

так а с кем парсер сравнивали?

> c JSON.stringify

а зачем сравнивать encode и decode? это же разные задачи

всмысле JSON.parse, конечно

всмысле JSON.parse, конечно

вы сравнивали JSON.stringify и JSON.parse друг с другом?

Нет

Парсер на C с JSON.parse

ERROR: S client not available

Парсер на C с JSON.parse

а каким? их десятки причем по скорости несопоставимых.

Не помню уже, какой-то из очень быстрых

> несопоставимых > несколько КБ ?

пасаны, в express-session указал secret, resave и saveUninitialized. все норм было. Потом подключил express-socket.io-session и в консоле начало выдавать что secret, resave и saveUninitialized не объявлены. Кто нить сталкивался?

например в го есть реализации работающие с json в 10 (!) раз быстрее чем стандартная библиотека, поэтому непонятно почему стандартная бибилотека эталон? тем более глядя на нативную реализацию в ноде промисов эпичную, которая нереально плоха была до недавнего времени

Но она как бы это сказать делает за счет типизации это.

Ну и дефолтная библиотека в Js лучше чем в go

Но она как бы это сказать делает за счет типизации это.

ну вот нет, стандартная либа и библиотека сторонняя написаны на одном языке у них равные возможности. вопрос в алгоритме.

Секрет просто - в Go просто плохая стандартная реализация

ну вот нет, стандартная либа и библиотека сторонняя написаны на одном языке у них равные возможности. вопрос в алгоритме.

Ты читаешь что я пишу?

Ты читаешь что я пишу?

да, кто там выигрывает за счет типизации?

О какой реализации в Go речь, для начала?

Секрет просто - в Go просто плохая стандартная реализация

не оптимальная, ровно как и в V8, но во втором случае что-то сделать сильно сложнее чем в первом

Секрет просто - в Go просто плохая стандартная реализация

Ну и это тоже. Но там выигрыш за счет того что они знают схему того что придет и все готово заранее. В принципе в Js вряд ли будет особый прирост поэтому поводу так как и приведение не нужно

Сложно утверждать, что в V8 не оптимальная реализация

Никаких свидетельств в пользу этого нет

О какой реализации в Go речь, для начала?

Н у наверняка чувак про мыловскую

Там где код заранее сгенерил для каждого типа меседжа.

О какой реализации в Go речь, для начала?

стандартная против jsonparser, но это другой язык и другая история

Ну ты сам эту историю привел, как бы

Сходу видно что этот парсер делает не то же самое, что стандартный парсер в Go

Следовательно сравнивать бессмысленно

Ты не получишь выигрыш из за того что нельзя сразу алоцировать память в хипе для объекта целиком и просто писать из экстрима туда

Никаких свидетельств в пользу этого нет

https://github.com/miloyip/nativejson-benchmark там есть и V8

> , allocates no memory

true story

https://github.com/miloyip/nativejson-benchmark там есть и V8

v8 против другого парсера, который выдает js-объекты?

v8 против другого парсера, который выдает js-объекты?

реализация парсинга на с/c++ там сравнивается, конвертация в js-объект задача уже другая

Это не так

Кстати а в V8 то на чём парсинг реализован?

Вот код из бенчмарка

А то многие почему то думают, что раз V8 то там и Array.map и промисы будут на крестах а не на js