Здравствуйте, L.K., Вы писали:
LK>А чем этот парсер лучше тысяч существующих?
ну...насколько я знаю, он быстрей тысяч существующих
LK>Ну, скажем, 100-меговый файл распарсивает за столько-то секунд. этот(52 мб) JSON за ~300 мс
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, L.K., Вы писали:
LK>>А чем этот парсер лучше тысяч существующих? X>ну...насколько я знаю, он быстрей тысяч существующих
LK>>Ну, скажем, 100-меговый файл распарсивает за столько-то секунд. X>этот(52 мб) JSON за ~300 мс
Лучше чем этот? Я в этих zero cost парсерах не очень разбираюсь, но такое на слабых камнях запускали. https://github.com/zserge/jsmn
Здравствуйте, Danchik, Вы писали:
D>Лучше чем этот? Я в этих zero cost парсерах не очень разбираюсь, но такое на слабых камнях запускали. D>https://github.com/zserge/jsmn
ну не знаю кто кого быстрее окажется... нужно тестить.
но удобней — однозначно)
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
В тестовых данных большого размера в основной ветке. Захочешь форкнуть (для PR или для включения сией библиотеки в проект) и приходится скачивать всё подряд. Да и неэстетично, в конце концов.
Здравствуйте, flаt, Вы писали:
F>В тестовых данных большого размера в основной ветке. Захочешь форкнуть (для PR или для включения сией библиотеки в проект) и приходится скачивать всё подряд. Да и неэстетично, в конце концов.
никогда не задумывался об этом...
а как в таких случаях хранят тестовые данные?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Справедливое замечание для обычного git clone, в принципе. Но репозитории библиотек я клонирую с --branch-only (с --depth 1, если история не интересна).
Но даже для обычного клонирования — другие ветки будут хотя бы нераспакованы и не захламляют каталоги зря.
X>никогда не задумывался об этом... X>а как в таких случаях хранят тестовые данные?
Отдельная ветка, а лучше — отдельный репозиторий для бенчмарков и тестовых данных. В конце концов, пользователю библиотеки нужен лишь заголовочный файл. Да, если озаботиться CI и/или релизами, то можно его выкладывать отдельно — но, опять же, стоит подумать и о тех, кто форкает или клонирует репозиторий.
Здравствуйте, niXman, Вы писали:
F>>В тестовых данных большого размера в основной ветке. Захочешь форкнуть (для PR или для включения сией библиотеки в проект) и приходится скачивать всё подряд. Да и неэстетично, в конце концов.
X>никогда не задумывался об этом... X>а как в таких случаях хранят тестовые данные?
А сгенерировать?
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, Danchik, Вы писали:
D>>Лучше чем этот? Я в этих zero cost парсерах не очень разбираюсь, но такое на слабых камнях запускали. D>>https://github.com/zserge/jsmn
X>ну не знаю кто кого быстрее окажется... нужно тестить. X>но удобней — однозначно)
Да тут уже не стояло требование по удобно. Пямяти в обрез, а парсить надо.
