Давно я сюда не писал, обходился Telegram и Twitter, но поля их слишком малы, чтобы вместить эту статью :)
Для небольшого исследования в области упаковки чисел мне понадобилось получить минимальное количество бит, требуемое для записи числа.
Его, конечно, математически можно получить с помощью двоичного логарифма “округлённого к большему целому” (буду использовать обозначение lg n).
Как вы, вероятно, знаете, в .NET Core 3.0 появились intrinsic’и[1], в частности, LZCNT. Она, конечно, возвращает leading zeroes,
но вычесть-то из 31 (для индекса в каком-нибудь массиве) или из 32 (для количества бит на число) недолго.
Однако, мне было интересно узнать и универсальное решение. В .NET Core 3.0, к счастью, добавили для этого класс BitOperations[2].
А мне, конечно же, захотелось посмотреть его исходники…
Если вы помните, давным давно я писал про srcset и sizes для картинок.
Эти атрибуты позволяют подсказать браузеру, какие картинки лучше грузить (работают для тэгов img и picture).
А сегодня увидел твит, который одной картинкой поясняет принципы работы. И решил напомнить вам эту тему.
Недавно вышла статья System.IO.Pipelines: High performance IO in .NET.
Она про то, как реализовать более наглядную и быструю работу со стримами в .NET Core 2.1.
От слишком краткого пересказа статья многое потеряет — читайте оригинал. Ладно, будем честными — я сегодня подустал, поэтому бегло её прочитал и не очень разбирался :)
CoreRT — поддержка native code для .NET Core.
Слишком коротко. Ладно, это проект, который делает из сборок для .NET Core машинный код.
И собирает в один файл вместе с рантаймом. Пока альфа.
Если хотите чуть больше подробностей — читайте дальше.
Рассказ, как обычно, будет коротким. Но со списком статей для дополнительного изучения :)
Пара статей Сергея Теплякова и мотивировала меня написать этот краткий конспект на русском языке.
Если вы готовы прочитать эту интересную, но огромную статью — прочитайте. Я всё-таки пристрастен и расскажу о том, что интересно лично мне.
А если не хотите читать и короткую…
TL&DR; Значительно (в 1.5-2 раза) улучшена производительность многих вещей, в том числе:
Структуры (Value types). Это ключевые изменения, многие оптимизации сделаны за счет Span<T> и Memory<T>.
Сравнения. Также оптимизированы сравнения внутри Dictionary .
Строки — оптимизированы не только сравнения, но и такие штуки как ToLower, Format и Parse.
С удовольствием прочитал статью High-performance .NET by example: Filtering bot traffic.
Кстати, к ботам статья почти не имеет отношения, а вот к улучшению производительности — очень даже. В частности,
есть примеры использования BenchmarkDotNet, PerfView, Intel VTune Amplifier, ILSpy, WinDbg и unsafe-кода.
Буквально пару слов об online-книге High Performance Browser Networking —
не читал, но одобряю :) Точнее, посмотрел одну из глав (бегло). Познавательно и по делу.
А toxiproxy — это набор от Shopify для тестирования сети в разнообразных условиях.
Состоит из TCP-прокси (на Go) и клиентских библиотек для подключения (Ruby, Go, Python, .NET, PHP, Node, Java).
Сегодня расскажу про два сравнительно простых способа как сделать ваших пользователей ещё счастливее.
Как вы уже знаете, мне нравятся быстрые сайты. Летом я уже делился набором инструментов для оптимизации сайтов.
Однако, есть пара несложных приёмов, первый из которых эти инструменты вряд ли когда-нибудь догадаются посоветовать.
Начнём с самого простого в реализации способа.
Его внедрение, правда, может отнять у вас много времени на этапе согласования в компании или с участниками вашей команды.
В последнее время всё чаще сталкиваюсь с разработкой на node.js.
На работе использую версию LTS, по понятным причинам. Дома поставил 6.3.1.
Идеологически мне больше нравится третий npm — всё-таки хранить дубликаты модулей, особенно когда их много — не здорово.
Кстати, для старой версии ноды есть модуль npm3 — позволяет
(в лучших традициях партизан) использовать новый npm при установленном старом (только команды будут npm3 install и т.п.). Но сегодня речь не об этом.
Сегодня поделюсь набором инструментов для оптимизации сайтов. Это больше про скорость, чем про SEO, хотя и для SEO там тоже есть много полезного.
К счастью, поисковики начали учитывать заодно и скорость загрузки сайтов при индексации.
Да, вероятно я перфекционист, однако я не могу спокойно смотреть на мегабайтные картинки и сайты, загружающиеся дольше секунды при нормальном соединении.
Правда, этот сайт я пока не оптимизировал на все 100%, но в этом случае я рисковал начать писать сюда в следующем году :)