#работа_со_строками — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #работа_со_строками, aggregated by home.social.
-
[Перевод] Структуры данных на практике. Глава 14: Обработка строк и эффективность использования кэша
«В Computer Science есть только две сложные вещи: инвалидация кэша и придумывание названий», — Фил Карлтон Разрыв в производительности Наш парсер логов обрабатывал 800 тысяч строк в секунду. Нам требовалось 3 миллиона строк в секунду. От нужного нам показателя мы отставали в 3,75 раза. Задача инструмента заключалась в парсинге строк логов в реальном времени, извлечении временных меток, уровней логов и сообщений из миллионов строк в секунду. Обработка миллиона строк логов в текущей реализации требовала 1,25 секунды — слишком долго для анализа в реальном времени. Профилировщик показывал 85 миллионов промахов кэша. Для обработки строк это казалось слишком большим показателем. В реализации использовались стандартные строковые функции C — простые, читаемые, но, очевидно, слишком медленные. Я переписал этот код, добавив обработку строк с учётом кэша. Результаты были такими: В 4,5 раза быстрее и в 7 раз меньше промахов кэша. В этой главе мы поговорим о том, как эффективно использовать кэш при обработке строк.
-
[Перевод] Структуры данных на практике. Глава 14: Обработка строк и эффективность использования кэша
«В Computer Science есть только две сложные вещи: инвалидация кэша и придумывание названий», — Фил Карлтон Разрыв в производительности Наш парсер логов обрабатывал 800 тысяч строк в секунду. Нам требовалось 3 миллиона строк в секунду. От нужного нам показателя мы отставали в 3,75 раза. Задача инструмента заключалась в парсинге строк логов в реальном времени, извлечении временных меток, уровней логов и сообщений из миллионов строк в секунду. Обработка миллиона строк логов в текущей реализации требовала 1,25 секунды — слишком долго для анализа в реальном времени. Профилировщик показывал 85 миллионов промахов кэша. Для обработки строк это казалось слишком большим показателем. В реализации использовались стандартные строковые функции C — простые, читаемые, но, очевидно, слишком медленные. Я переписал этот код, добавив обработку строк с учётом кэша. Результаты были такими: В 4,5 раза быстрее и в 7 раз меньше промахов кэша. В этой главе мы поговорим о том, как эффективно использовать кэш при обработке строк.
-
[Перевод] Структуры данных на практике. Глава 14: Обработка строк и эффективность использования кэша
«В Computer Science есть только две сложные вещи: инвалидация кэша и придумывание названий», — Фил Карлтон Разрыв в производительности Наш парсер логов обрабатывал 800 тысяч строк в секунду. Нам требовалось 3 миллиона строк в секунду. От нужного нам показателя мы отставали в 3,75 раза. Задача инструмента заключалась в парсинге строк логов в реальном времени, извлечении временных меток, уровней логов и сообщений из миллионов строк в секунду. Обработка миллиона строк логов в текущей реализации требовала 1,25 секунды — слишком долго для анализа в реальном времени. Профилировщик показывал 85 миллионов промахов кэша. Для обработки строк это казалось слишком большим показателем. В реализации использовались стандартные строковые функции C — простые, читаемые, но, очевидно, слишком медленные. Я переписал этот код, добавив обработку строк с учётом кэша. Результаты были такими: В 4,5 раза быстрее и в 7 раз меньше промахов кэша. В этой главе мы поговорим о том, как эффективно использовать кэш при обработке строк.
-
[Перевод] Структуры данных на практике. Глава 14: Обработка строк и эффективность использования кэша
«В Computer Science есть только две сложные вещи: инвалидация кэша и придумывание названий», — Фил Карлтон Разрыв в производительности Наш парсер логов обрабатывал 800 тысяч строк в секунду. Нам требовалось 3 миллиона строк в секунду. От нужного нам показателя мы отставали в 3,75 раза. Задача инструмента заключалась в парсинге строк логов в реальном времени, извлечении временных меток, уровней логов и сообщений из миллионов строк в секунду. Обработка миллиона строк логов в текущей реализации требовала 1,25 секунды — слишком долго для анализа в реальном времени. Профилировщик показывал 85 миллионов промахов кэша. Для обработки строк это казалось слишком большим показателем. В реализации использовались стандартные строковые функции C — простые, читаемые, но, очевидно, слишком медленные. Я переписал этот код, добавив обработку строк с учётом кэша. Результаты были такими: В 4,5 раза быстрее и в 7 раз меньше промахов кэша. В этой главе мы поговорим о том, как эффективно использовать кэш при обработке строк.
-
Зоопарк строк в вашем C++ коде?
CryEngine2 использовал класс собственный CString, для реализации работы со строками и немного использовал строки из стандартной строковой библиотеки Windows. Насколько я помню, последняя версия CryEngine всё ещё использует те же самые CString, она кардинально поменялась внутри, но как дань истории название класса менять не стали, зато сильно расширили функционал. Я не на 100% уверен, применялся ли CString только в редакторе или в рантайме игры тоже, вы можете сами это посмотреть в исходниках, которые все еще доступны на гитхабе. Это один подход к работе со строками, довольно распространненный в мире игростроя - когда мы все нужное пишем сами, не оглядываясь... хотя, тут больше уместно слово поглядывая, на существую реализации и утаскивая в проект все самое лучшее. Есть и другой подход... Я работал в команде над некоторым проектом, который должен был выйти на консолях, и в какой-то момент на проект пришел эффективный тимлид, который хорошо умел в красивые презентации, и продавил использование std::string из sdk. Все очень опытные программисты, синьоры и руководство важно кивали на совещании и согласились всё перевести на std::string… не такие уж они оказались опытные, как выяснилось. В итоге мы заменили большую часть CString на std::string. Не сказал бы, что это сильно повлияло на время компиляции - плюс-минус минута к проекту, который собирается двадцать минут особой погоды не делают, но это также превратило наш довольно понятный базовый код в запутанный кошмар. Возможно, для переносимости это было лучше, но ни наш проект, ни CryEngine2 Editor так и не были портированы ни на Linux, ни на какую-либо другую платформу. Прошло десять лет, я вижу ровно туже ситуацию на текущем проекте - новый тимлид решил перевести местный MySuperPupeString на std::string, уже предчувстуя "нижней чуйкой" последствия - запасаюсь попкорном и беру отпуск на следующий месяц после принятия решения. Но не это интересно, а то - какие вообще строки могут быть в вашем с++ коде. Строка, на строке и строкой погоняет
-
[Перевод] Самый быстрый способ нахождения гласной в строке
Недавно меня заинтересовала такая задача: как лучше всего определить, что в строке есть гласная? Казалось бы, тривиальный вопрос, правда? Но, начав разбираться, я осознал, что задача гораздо глубже. Я бросил себе вызов: придумать как можно больше способов обнаружения гласной. Я даже попросил присоединиться ко мне нескольких друзей. Какой способ самый быстрый? Каким никогда не стоит пользоваться? Какой самый умный? Какой самый удобочитаемый? В этом посте я рассмотрю 11 способов обнаружения гласных, алгоритмический анализ, дизассемблирование байт-кода Python, реализацию CPython и даже исследую опкоды скомпилированного регулярного выражения. Поехали!
-
[Перевод] Как мы пишем код для curl на C
Мне часто задают такой вопрос: как мы пишем на C код для curl , чтобы он был безопасным и надёжным в миллиардах установок? Мы предпринимаем определённые меры и принимаем решения. «Серебряной пули» нет, есть только рекомендации. Как вы убедитесь сами из этой статьи, в них тоже нет ничего странного или неожиданного. «c» в слове «curl» не обозначает и никогда не обозначало язык программирования C, это расшифровывается как client. Предупреждение Этим текстом мы ни в коем случае не хотим сказать, что иногда случайно не мерджим баги, вредящие безопасности. Это происходит. Мы люди, мы совершаем ошибки. А потом мы их устраняем.
https://habr.com/ru/articles/898714/
#curl #integer_overflow #переполнение_int #парсинг #работа_со_строками
-
[Перевод] strlcpy, или как CPU противоречат здравому смыслу
Один из моих старых постов о strlcpy недавно вызвал обсуждения на различных форумах. Вероятно, с этим как-то связан выпуск новой версии POSIX. Многие авторы приводили один контраргумент, который я слышал и раньше: «В общем случае, когда исходная строка умещается в конечный буфер, strlcpy будет обходить строку только один раз, а strlen + memcpy будут обходить её дважды». Под этим аргументом скрывается допущение о том, что однократный обход строки выполняется быстрее. И, честно говоря, это вполне разумное допущение. Но справедливо ли оно? Об этом мы и поговорим в статье.
-
[Перевод] Быстрый парсинг 8-битных целых чисел
Допустим, вам нужно быстро распарсить 8-битные целые числа (0, 1, 2, …, 254, 255) из строки ASCII/UTF-8. Задача взята из проекта simdzone под руководством Йероена Коеккоека (NLnet Labs). Дана строка и её длина: например, ’22’ и длина 2. Наивное решение на C может выглядеть так:
-
[Перевод] Быстрый парсинг 8-битных целых чисел
Допустим, вам нужно быстро распарсить 8-битные целые числа (0, 1, 2, …, 254, 255) из строки ASCII/UTF-8. Задача взята из проекта simdzone под руководством Йероена Коеккоека (NLnet Labs). Дана строка и её длина: например, ’22’ и длина 2. Наивное решение на C может выглядеть так: