Comments 95
Я смотрю, уже давно, в сторону V8. Но, проблемы с ним очевидны, меняется он исключительно под нужды хрома. На данный момент я не осилю свой JS движок, это фантастика. Как бы не кололось прийдётся взять чужое. Если денег найду то будет своё. Сейчас цель движок/расчёты/отрисовка.
Удачи!
Ресурсы да, но он очень медленный. Из-за того, что он позиционируется как встраиваемый и "лёгкий" он медленный. К тому же, он поддерживает только ECMA 5.1. В общем, хочется скорости и современности.
UPD. Таки есть.
jmem_pools_collect_empty(), jmem_run_free_unused_memory_callbacks()
меняется он исключительно под нужды хрома
К сожалению, сейчас почти весь веб пишется «под нужды хрома». Думаю если возьмете V8 — ничего не потеряете.
Это вторая статья из цикла. Первую можно увидеть в моём аккаунте. Добавлю сегодня ссылку в статью.
Не пробовали смотреть в сторону какого-нибудь другого языка вместо C? Например D в режиме BetterC. Бонусом должно быть ускорение времени компиляции проекта (к линковке, конечно, не относится).
Браузерный движок — это ОС, без преувеличений. Меня интересует скорость и ручное управление памятью. Плюс, обязательно встраиваемость в другие языки программирования. Не уверен, что D подходит для этого.
C++ ооочень медленно компилируется, поэтому я даже не представляю как можно собирать проекты уровня Blink на домашней машине средней руки. D в режиме BetterC (это ключевой момент) как раз-таки очень хорошо должен вам подойти, просто гляньте на спеку: https://dlang.org/spec/betterc.html, там вообще нет рантайма кроме libc.
По сути это и есть C, только без заголовочных файлов (с модулями) и с разными очень удобными плюшками типа ranges, удобного foreach, array slices, RAII и т.д. Для ручного управления памятью никто не запрещает вызывать привычные malloc и free, либо подключить какие-то другие аллокаторы.
Сам D очень хорошо (полностью совместим) интерфейсится с C и чуть похуже с C++ (в основном из-за премудростей с интерфейсами и наследованием в классах), так что встраиваемость будет на отличном уровне.
Причина по которой я рекомендую именно D — в скорости компиляции оного референсным компилятором. Ни C, ни особенно C++, не смогут в такое просто из-за особенностей языка — наличие заголовочных файлов само по себе усложняет компиляцию.
Еще как вариант есть Rust, но у него со скоростью компиляции тоже вроде бы не все так хорошо (знатоки, поправьте, если что-то изменилось). Да и порог входа там тоже никто не отменял.
Си распространен настолько, что нет опасности, что его забросят или ключевые разработчики уйдут.
Си быстро компилируется. Да, если написать ядро линукса на плюсах то оно не соберётся никогда. По этому, я выбрал Си.
Насчёт забросить, — да, вроде за 19 лет не забросили.
Что касается микроволновки, то это конечно перебор, но вот, например, для OpenBSD пока действительно нет компилятора D (ни DMD, ни GDC, ни LDC).
Причём здесь ядро Линукса, которое не соберётся на C++, и как из этого следует выбор C, я не совсем понял.
Скорость точно такая же как и в C/C++, так как бэкенды те же. Однако референсный компилятор оптимизирует хуже чем два других — LDC и GDC (с GCC бэкендом), а также не умеет в кросс-компиляцию, поэтому если нужны крутые оптимизации и микроволновки с чайниками, то собирать нужно через LDC, т.к. это компилятор на основе LLVM бэкенда (уже WASM даже работает). Но с ним и сама сборка будет медленнее, поэтому LDC в основном используют для продакшн билдов.
Вот вводная справка по компиляторам D: https://wiki.dlang.org/Compilers
Сам язык относительно недавно включили в состав GCC: https://www.opennet.ru/opennews/art.shtml?num=49546
Основатель и создатель языка — Уолтер Брайт: https://en.wikipedia.org/wiki/Walter_Bright
, он же создатель одного из самых первых полноценных компиляторов C++. С ним в паре работает Андрей Александреску — очень известный товарищ из мира C++. Также существует некоммерческая организация D Foundation, которая используется как раз для организации спонсорской помощи. С корпоративным уровнем у них там все достаточно серьезно, но все-таки сказывается отсутствие крупных спонсоров типа Google, Microsoft и т.д., но некоторые считают что это даже к лучшему.
Вот список организаций которые использовали или используют D: https://dlang.org/orgs-using-d.html
Самому языку на самом деле уже больше 10 лет, но у него сложная история. Популярным его не назовешь, но и умирать он точно не собирается (в виду наличия достаточно большой кодовой базы в некоторых крупных коммерческих проектах) и постепенно развивается, конечно не такими темпами как более попсовые Go и Rust.
Если надо собирать под какие-то специфические микроконтроллеры, то тут вы правы — лучше взять С, так как его компиляторы есть практически везде.
По эффективности же (для программиста) D превосходит оба языка из-за наличия в нем современных языковых средств, которые, кстати, C++ активно тащит в свои новые стандарты копируя их с D.
Тем не менее, в режиме BetterC у вас не будет замыканий, т.к. они требуют сборщика мусора, а также классов с их наследованием. Но т.к. у вас ручное управление памятью и в целом минимализм, то они вам и не нужны =D
Еще из недостатков можно отметить пока что слабую поддержку IDE, хотя она есть.
В общем рекомендую просто потратить пару дней и попробовать написать что-то что у вас уже написано на C, но только на подмножестве BetterC. Порог входа для вас будет нулевой (в виду практически полной совместимости с C), а приятных бонусов гораздо больше.
Можете пройти небольшой тур для ознакомления с общими принципами языка: https://tour.dlang.org/tour/ru/welcome/welcome-to-d
Одно могу точно сказать — попробовав D (даже в урезанном виде) потом будет очень больно слезать назад на C и C++.
Но если у вас есть какие-то специфические требования, то тут конечно лучше вам смотреть предметно самостоятельно, описать все в одном комментарии сложно. Может C в вашем случае действительно более подходящий выбор.
Я посмотрю, для общего развития, на D. Но, данный проект (Lexbor) будет развиваться на Си.
Да не за что! =)
D очень интересный язык с той точки зрения, что пытается исправить неудачные решения в C и C++ при этом не сдвигая целиком всю парадигму, как это делает, например, Rust.
Смотрю что Ваше предыдущее сообщение (да и мои тоже) уже успели заминусовать добрые посетители Хабра. Если что, то это не я. Обычно таким не занимаюсь =)
Всеми руками и ногами поддерживаю Ваше начинание! Сейчас в этой нише очень уж мало легковесных встраиваемых решений для рендеринга HTML. В приципе есть Sciter (его вроде уже упоминали), но он совсем не опен сорс и является платным для коммерческого использования.
Так что было бы здорово, если бы у Вас все получилось!
На мой взгляд скорость компиляции важна для программиста: чем меньше времени уходит на цикл разработки, тем лучше. Среди двух языков с одинаковой скоростью исполнения и примерно одинаковыми характеристиками я бы выбрал тот, который быстрее компилируется. Мне кажется это логичным.
Не совсем понимаю при чем здесь Delphi.
У компилятора Delphi относительно мало семантики и компиляция кода может происходить за один проход. Что собственно дает окололинейную скорость.
Опять же повторю — грамотная модульность проекта уменьшают количество юнитов для компиляции и облегчают тестирование этих самых модулей. Инкрементальная сборка при модульной же архитектуре позволят пересобирать не весь код, а только тот модуль который был непосредственно зацеплен. Так что время компиляции, особенно на том этапе, на котором находится автор статьи, не должно быть сколько-нибудь серьёзным препятствием для разработки.
Даже для такого жесткого компилятора как в Rust с его доказательным компилятором время компиляции не настолько большая проблема(теперь уже).
… что в первом случаи...
… благодаря обработки...
… есть пару моментов...
… к нам прийдет текстовый...
Может оттолкнуть многих (я, например, на каком-то подсознательном уровне не могу серьезно относиться к тексту, в котором неправильно склонены существительные). Попробуйте почистить статью от этого, так она станет намного лучше.
А если возможно, то какие минусы? Они же должны быть, раз этого еще не сделали.
Но, при этом, основная цель быстрый браузер.
Из минусов. За всё приходится платить. В основном памятью. Моя задача минимизировать это. Максимум скорости при минимальном потреблении ресурсов.
Ко мне обращался один из разработчиков UI для автомобилей. Мы обсуждали можно ли при минимальных затратах ресурсов использовать данный подход. Интерес к этому есть.
А не сделали это по простой причине — сложно. Не ради рекламы, но таких буйных как я мало. Посмотрите у кого есть свои браузерный движки. Даже у Яндекса его нет, они пользуют гугловский. Сложность колоссальная.
Успехов вам, постараюсь поддержать проект чем смогу :)
Ко мне обращался один из разработчиков UI для автомобилей.
Не вижу тут пробоем с ресурсами. Например Mercedes Qt засунул.
А если возможно, то какие минусы? Они же должны быть, раз этого еще не сделали.
Давно уже вроде сделали, насколько я помню интерфейс некоторых антивирусов написан на
https://sciter.com/
У меня подход другой. Я создаю полноценный движок на Си с возможностью встраивать в любой язык программирования. Плюс, лицензия у меня очень свободная: Apache 2.0. То есть, использовать можно хоть где и хоть как.
История создания Sciter: sciter.com/10-years-road-to-sciter
«обрезанную версию движка для интерфейсов»
Не сказал бы что обрезанная ибо HTML5 и CSS3 (избранные модули) поддерживаются практически в полном объеме.
Вот «полноценный движок на Си» сделать действительно крайне сложно. С это не тот язык на котором такие вещи удобно писать.
И желание «встраивать в любой язык программирования» тоже вызывает вопросы.
Сейчас Sciter встраиваем в C/C++, C#, Rust, Python и Go. и написан на C++. Embedding API тот, да, plain C ибо другой альтернативы нет.
Но на самом деле встраивание в язык это дело десятое. Вот встраивание в существующие десктоп системы и графику это важно.
Сейчас Sciter может работать на Windows (XP … 10) c Direct2D/DirectWrite (DirectX), Skia (OpenGL) и GDI+ (прости мя сирого, хоспидя). На Mac — CoreGraphics и OpenGL(Skia), Linux/GTK (cairo или Skia). На подходе Andorid (OpenGL) и iOS (CoreGraphics или OpenGL).
Skia и Direct2D это C++ и только. Ибо Skia можно интегрировать только в исходниках а это С++. А Direct2D это IUnknown со товарищи, т.е. C++ опять же.
Без Skia и Direct2D (т.е. hardware acceleration) делать rendering engine можно и не начинать. 4K мониторы это наше все теперь. А на них только H/W acceleration — других опций и нет.
Об удобстве написания речь не идёт. Хотя, тут на вкус и цвет все фломастеры разные. Главное, чтобы использовать удобно было. Си именно даёт «Embedding API» из коробки. Не нужно делать двойную работу, проектировать дополнительный апи. Так же, все структуры видны. Я совершенно не противник плюсов, они мне даже нравятся, но данный проект именно на Си.
Желание встроиться в любой язык программирования у меня не вызывает вопросов. Тут, как раз, всё прозрачно. Я отлично понимаю (в NGINX сейчас тем и занимаюсь) как писать сишные расширения для Python, Node.js, Perl, PHP, Ruby и имею представление о Go.
Ну, слушайте, я вообще ещё не говорил о рисовалке. Тут, как говориться, ежу понятно, что она должна быть «hardware acceleration». Не открывая гугл, Skia вроде хром и лиса пользуют, говорят очень быстрая.
На данный момент стоит задача создания дерева отрисовки. Все расчеты, перерасчёты и так далее. При этом, делать всё это максимально быстро. Без рисования вообще. Но, сразу скажу, есть чёткое понимание как всё делать. Обсуждение бекенда рисовалки идёт постоянно. Приоткрывая занавес: у меня уже есть свой движок, всё что я выкладываю в публичный доступ это чистовик, черновик так и останется у меня.
P.S.:
Тысяча извинений. Из вашего сайта не понятно, что поддерживается, а что нет. Складывается впечатление, что как-то обрезано.
При этом, наши дороги немного расходятся. Не знаю насколько выгодно продавать лицензии, но я делаю open source, а деньги извлекать буду другим методом. Да и речь тут даже не о деньгах.
Не ясна модель встраивания в другие языки. Поэтому и вопросы.
Если бы ты (можно без «вы»?) определил изначально периметр встраивания (API другими словами) то было бы наверное более понятно что оно такое будет.
Скажем весь Sciter API это вот эта структура github.com/c-smile/sciter-sdk/blob/master/include/sciter-x-api.h — там реально 40 функций (DOM related).
Это чистые C functions хотя написаны на C++. И то на чем они написаны вообще никого не волнует. И не должно. Далеко не все «структуры» вообще могут быть выставлены наружу. Это банально опасно. Только контролируемый периметр.
«есть чёткое понимание как всё делать»
У меня было это состояние лет так 14 назад. И более того был реальный опыт создания WYSIWYG редакторов что близко к HTML (и там и там DOM, parsing и всё такое). Реальность как всегда оказалась несколько далека от изначальной теории.
Как я понимаю до слов harfbuzz (и вообще RTL), writing script itemizer and shaper, и прочая ты еще не добрался. (сужу по описанной структуре parser. Кому нужны эти «Character token» и что это вообще?)
«я вообще ещё не говорил о рисовалке.» и "… дерева отрисовки. Все расчеты, перерасчёты и так далее."
Ну да, теоретически ты можешь рассчитать положение примитивных прямоугольных блоков, но для glyph positioning придется учитывать такие вещи как ClearType и другие механизмы которые доступны на конкретных платформах и которые являются частью rendering механизма. Это суровая практика, сиречь необходимость. Без понятия архитектуры rendering с самого начала и как те glyphs оказываются в GPU памяти что-то практическое сделать невозможно.
И еще, я ни в коем случае не хочу тут рисовать картину маслом «Умерщвление прекрасной гипотезы мерзким фактом». Можно написать HTML/CSS/script engine и одному, собственно sciter есть тому подтверждение. Но нужно изначально определить «а user кто?». Для чего это всё? Т.е. почему проект который сейчас использует WebKit или Sciter должен перейти на твой движок?
Если это для того чтобы сделать что-то типа HTML-to-PDF утилиты, то это одно. Для UI же… С его анимациями и рисованием на 4K мониторе full screen и c 60 FPS это совсем другое — как минимум layout engine должен взаимодействовать с rendering engine чтобы получать вектора glyphs и прочая. DrawText примитивы уже не работают на таких потоках данных и скоростях.
И еще по поводу языка. Sciter написан на «C c классами» по большому счету. Ибо это удобно — т.е. позволяет быстрее и что главное надежнее писать. (Sciter примерно 100 тыс LOC). Это всё важно для one-man-project. А Mozilla вообще пилит Rust для того чтобы писать Servo — ручное управление памятью для проектов такого масштаба даже для них оказалось суровой задачей.
И по поводу Open Source. Не советую обольщаться на эту тему.
Есть два типа проектов: небольшие утилиты и что-то типа Electron. Первые имеют смысл для Open Source. Вторые же… Ну вот реально никого не парит что там внутри — реально количество людей которые лезут в детали WebKit или Gecko исчисляется десятками на всём шарике. И вот собственно и вся аудитория для open-sourse-ности проектов такого уровня. Тем более в свете последних скандалов с NPM ( в Microsoft Visual Code пролезла закладка которая тырит Bitcoins ) народ оченно печально настроен.
То что мы видим в OpenSource это верхушка айсберга. Реально же 90% софта это проекты по месту — внутренних IT отделов компаний. Да и те же китайцы. Любят они OpenSource. Но вот не знаю ни одного OS проекта финансируемого ими. Нет таких. Не потому что они такие-сякие, а потому что через их firewall такие платежи не сделать. Да и вообще поток статей типа FOSS is free as in toilet в последнее время оптимизма никак не внушает.
Весь комментарий основан на предположениях и доводах. Я понимаю, что тебе что-то было очень сложно сделать, отрывки этого я вижу в твоих комментариях. Ты пишешь очевидные вещи. Ещё раз, движок есть, пишется чистовик. По мере написания компонентов будут выходить статьи. И будут статьи о всё "сексе" с глифами, расчетами.
Так же, я веслом не ударен, чтобы строить наивные предположения, что щас вот героически всех… Если посмотреть в мой профиль, то можно понять, что этим я занимаюсь больше 5 лет.
Про open source. Я работаю в компании которая занимается этим самым опен-сорсом — NGINX. Я чётко представляют, что это такое. Иллюзий нет, вообще, нет и не было. Мой проект есть и будет под лицензией Apache 2.0.
Чувак, как ты парсер то писал хтмл? Character token. Шучу :)
Статья про быстрый парсинг. Остальное будет.
И в завершении. Я реально рад, что есть такие проекты как ваш. Ваш проект придаёт уверенности и сил сделать свой движок. Некий буст.
Я вполне рад пообщаться с вами вне хабра. Всё же, почти, одно дело делаем.
Как только вышла GraalVM, первое что пришло на ум — на ее основе получился бы не плохой полиглот-браузер. Что если ее взять за основу?
Смотря на их сайт, я не могу придумать как там привинтить браузер.
1) lex — лексический (lexical). В линуксе даже программа такая есть, так и называется lex (лексический анализатор). Потому, что в браузерном движке много парсинга: html, css, font, url, js много всего.
2) bor — думаю тут и так всё ясно. Транслит нашего слова бор. Лесной бор. В начале хотел назвать lextree. Но потом, подумав, выбрал lexbor.
И уже потом, я осознал, что на GitHub у меня аккаунт lexborisov. То есть, начало от lexbor. В общем, сам Бог велел. Так и оставил.
При этом, вы сильно утрируете (доводите до абсурда), вы бы ещё, для примера, объединили арабскую вязь и иероглифы.
Вообще хорошее имя и логотип довольно сильно сказываются на впечатлении пользователя. Хотя об этом рановато думать =)
Энтузиазм не угрохается. Я занимаюсь этим не первый год.
Можно.
>Тут закладываются основы.
Нет.
>Энтузиазм не угрохается. Я занимаюсь этим не первый год.
Ок. Просто визуальные вещи привлекают больше внимания. И если они есть в проекте, то лучше начинать с них.
просто сделали рендер в той степени, в которой нам было нужно.
Какова эта степень этой простоты?
И CSS парсилку вы у кого-то взяли. Насколько быстро у вас всё это работает? Всё "органично" вписалось друг в друга? И работу со "сборкой мусора" вы написали. Он у вас динамически всё перерисовывает?
Речь идет о реализации быстрого браузерного движа. Если взять медленный и давно устаревший gumbo + прикрутить какой нибудь css парсер то речи о быстроте быть не может. Зачем писать рендеринг если вокруг все на соплях?
Затем, чтобы привлечь внимание к проекту. Еще раз — визуальные вещи привлекают больше внимания к проекту, чем какие-то непонятные парсеры. Или вам еще нужно разъяснять, почему важно внимание к проекту?
Когда привлечёте внимание, сделаете нормальные парсеры, хоть на ассемблере.
Внимание кого? Ответьте на этот вопрос.
- Разработчиков? Так если я сделаю все из говна и палок, при этом показывая как у меня что-то отрисовывается, люди использовать это не будут, это невозможно будет использовать. Потому как АПИ будет ломаться постоянно. Да и похвастаться чем? Скорость? Низким потреблением ресурсов? — нет, ничего этого не будет. Будут лишь какие-то огрызки, а потом чтобы привести эти огрызки в нормальный вид уйдёт ещё больше времени. Адаптировать чужое, часто, намного сложнее чем написать своё. Учитывая, что речь идёт именно о скорости.
- Инвесторов? Я разговаривал с ~5 инвесторами. Люди хотели вложить в проект деньги, в разработку. Речи о "покажи нам картинку и тогда мы поверим" не шло. Отказал всем по разным причинам. В основном из-за расхождения целей.
Подход должен быть последовательный. Снизу вверх. Появляется новый модуль и его сразу же можно использовать. Использовать не только для браузерного движка, но и для других целей.
Разработчиков, инвесторов и т.д.
>Да и похвастаться чем?
Не знаю, вы вот пока хвастаетесь быстрыми парсерами. Мне это не интересно, думаю другим разработчикам тоже. Этих парсеров валом, скорость там не самая важная вещь.
А вот рендеринг это более интересная вещь, она привлекает внимание. И внимание измеряется в количестве узнавших о вашем проекте людей, заинтересованных принять в нём участие.
Я бы, например, начал пробовать прикрутить ваш рендеринг к GraalVM и мне было бы неважно какой у вас там быстрый парсер. И из каких палок он сделан.
>Я разговаривал с ~5 инвесторами.
Могли бы разговаривать с большим количеством инвесторов, будь у вас хоть какой-то рабочий рендеринг.
>Использовать не только для браузерного движка, но и для других целей.
И многие используют ваш парсер?
Я вас услышал.
Если вам что-то не нужно, это не значит, что это не надо остальным.
И многие используют ваш парсер?
Много, даже деньги платят за биндинги и доработки. И благодарности, что вместо 20 серверов теперь используют 8. Смотрите на myhtml.
Для CSS katana. Из поддержки html ограничились тегами h1, h2, h3, h4, h5, h6, p, br, b, u, s, span, strong, img, a, pre, ul, ol, li, div, video, blockquote, i, em, sup, sub.
В CSS ограничили до width, height, display, color, background, margin, padding, border, line-height, text-align, vertical-align, font-size, font-weight, text-decoration, cursor, word-wrap, list-style-type. Естественно выделение текста, событие клика по ссылке, ховер на ссылках. Сам посебе рендер не зависит от CSS/HTML парсера, он зависит от спецификаций как рендерить этот html.
Зачем писать рендеринг если вокруг все на соплях?
Почему на соплях? У нас не стоит цель написать свой браузер, мы хотим лишь иметь возможность в наших контролах использовать HTML. Это нормальное желание, когда люди пишут свой UI framework. В том же Qt не весь html поддерживается.
Сам посебе рендер не зависит от CSS/HTML парсера, он зависит от спецификаций как рендерить этот html.
Зависит, ещё как зависит. Расчеты и отрисовка HTML это есть итоговый комплекс парсинга и преобразований. Даже поведение отрисовки меняется в зависимости от html и css. Как он может не зависеть? Вы можете начать писать Layout без html, css, font (парсинг, расчеты глифов)?
То, что вы описали я могу сделать буквально сейчас используя свой Modest.
Как он может не зависеть?
Позвольте поинтересоваться, как он может зависеть? С моей точки зрения в рендеринг должны просто скормиться готовые дерево элементов и стили, а откуда они взялись — распарсились или захардкодил кто-то или из какого-нибудь gumbo или результат манипуляции джаваскрипта с DOM (без innerHTML) — абсолютно неважно. (Я не претендую на богатый опыт «в написании быстрых и эффективных браузерных движков», так, интересующийся мимокрокодил)
Делаете простейший парсер с отображением на ваши DOM структуры. Опять же DOM структуры для начала делаете простейшие, только самые важные поля и элементы. На этом делаете рендеринг. Привлекаете внимание. Допиливаете парсер и структуры до полной спецификации.
В общем, я вас понял.
Когда приступите к рендерингу, есть это в вашем роадмапе на ближайшее время?
Из отличительных черт — не аллоцирует память в процессе работы. В смысле вообще. Классический finite state automata — pull parser.
Документация не полная, и зачастую пишется "второпях", но она есть и соответствует действительности.
Пошёл смотреть примеры и тут я заметил, что названия тегов, атрибутов и их значений передаются в функцию с их размером. Серьёзно?
Абсолютно серьёзно. Данные у вас могут быть не зануленными.
Или такими способом достигается перформанс?
Б — безопасность. В большинстве случаев компиляторы посчитают размер строки в момент компиляции, но часто мы имеем данные из буферов в рантайме, и часто данные не занулённые. При этом, если вы каждый раз будете пересчитывать строку, то да, о производительности такого кода говорить не стоит.
Вы сейчас серьёзно? Прострелить ногу от того, что явно передаёшь размер данных?
Скажите это ребятам из MS, там вообще запрещают пользовать memcpy, заставляют использовать memcpy_s (с передачей размера). Смотрите описание.
В сях, правильным поведением является передача размера входных данных. Вы всегда можете сделать strlen() и компилятор оптимизирует.
токенизатор принимает на вход юникод символы
А зачем всё переводить в Unicode?
50% (условно) в HTML именно markup. Зачем эти 50% через конвертор-то гонять?
Как-то это не согласуется с заявленной целью «самый быстрый HTML-парсер c DOM.»
Чувствую, что как-то общение между нами не задалось.
Вы читали спецификацию HTML? Птиченька-намёкенька.
Давайте почитаем как разные кодировки устроены. У вас точно HTML?
Но, в статье описано, более того, в коде можно посмотреть как реализовано у меня. Ещё Modest посмотрите (проект остановлен). Там, кстати, можно увидеть попытку с глифами и расчётом, наивную попытку.
Как-то это не согласуется с заявленной целью «самый быстрый HTML-парсер c DOM.»
Вы сомневаетесь? А вы потестируйте со своим. Ваш код в студию!
Вы читали спецификацию HTML?
Более того, я (в том числе) её писал. Как Invited Expert @ W3C HTML5 WG и WHATWG.
Ты наверное не понял что я имею ввиду. Скажем у тебя есть HTML в кодировке UTF-8 на входе. Т.е. 50% твоего текста это ASCII. Зачем эти 50% вообще куда-то конвертировать?
Тебе нужно конвертировать содержимое text nodes. И некоторых атрибутов. И только. Зачем дурную работу делать?
А код я привел выше. Еще раз: www.codeproject.com/Articles/14076/Fast-and-Compact-HTML-XML-Scanner-Tokenizer
У нас идеальный мир? У нас только utf-8 приходит? А если utf-16 на вход. Почитай спеки encoding. Ссылку же дал. Ну в самом деле-то.
> 40 MB of XML per second
Ясно, понятно.
Я всегда хотел поучаствовать в написании хтмл спеки. Но, для меня это непостижимо, я тут «горшки обжигаю».
> Тебе нужно конвертировать содержимое text nodes. И некоторых атрибутов. И только. Зачем дурную работу делать?
Ещё раз перечитай статью и посмотри исходники.
Жаль, что общение с превратилось в фарс.
myhtml тоже гляньте гласком. Прошлый проект.
Разрабатываем свой браузер с нуля. Часть первая: HTML