Кому не нравится LINQ в C#? Встроенная и уже достаточно старая фича языка C# и рантайма .NET.
Но можем ли мы сделать более эффективную версию этой фичи?
TL;DR (спойлер)
Можем сделать более эффективную, но намного менее универсальную. Github проекта.
Рубрика «производительность» - 3
Как LINQ, только быстрый и без аллокаций
2022-01-30 в 10:03, admin, рубрики: .net, C#, c#.net, generics, linq, performance, производительностьКак я в десять раз ускорил работу таблицы Google одной строкой CSS
2021-12-02 в 12:38, admin, рубрики: css, dom, Google, timeweb_статьи_перевод, Блог компании Timeweb Cloud, веб-сайты, производительность, Разработка веб-сайтов, скроллинг, тестирование, фронтендНаша компания использует Google Search Console для проверки статуса индексации и оптимизации видимости наших веб-сайтов. Также в консоли можно проверить, какие внешние веб-сайты ссылаются на вашу страницу. Однажды я просматривал страницу «Top linking sites» и заметил сильное торможение скроллинга. Оно происходило, когда я выбирал отображение большого массива данных (500 строк) вместо стандартных 10 результатов.
Раздел «Top linking sites» в Google Search Console, 500 строк на страницу
Я интересуюсь производительностью фронтенда, поэтому не мог удержаться и решил разобраться, в чём дело. В конце концов, Google активно стремится к повышению веб-производительности, поэтому стоит ожидать, что собственные публичные приложения компании будут хорошим эталоном.
Читать полностью »
Jetpack Microbenchmark — тестируем производительность кода
2021-09-21 в 8:30, admin, рубрики: anroid, jetpack, kotlin, microbenchmarks, mobile, performance, Блог компании FunCorp, производительность, разработка мобильных приложений, Разработка под android, Тестирование мобильных приложений
В мобильной разработке периодически возникают ситуации, когда нужно оценить время выполнения кода. Помимо теоретических подходов (например, Big O), которые позволяют отсеять очевидно неудачные решения, существуют бенчмарки для тестирования кода и поиска более мелких отличий.
Does the latency matter?
2021-09-10 в 7:21, admin, рубрики: highload, highload systems, http, latency, request, request time, TLS, Блог компании Конференции Олега Бунина (Онтико), высокая производительность, производительность, производительность приложений, производительность сайта, распределенные системы, Сетевые технологии
Есть исследование от Google, которое говорит, что если ваш сайт открывается больше трех секунд, то вы потеряете около 40% десктопных пользователей и более 50% — мобильных. Еще есть репорт от Amazon, который говорит, что для Amazon каждые 100 мс дополнительного latency стоит им 1% продаж. В объемах Amazon это миллионы долларов.
В зависимости от вашего бизнеса вам стоит тоже ответить на вопрос: Does the latency matter?
Как мы использовали расширенную статистику Postgres и ускорились в 2850 раз
2021-08-22 в 13:41, admin, рубрики: join, postgres, postgresql, skillfactory, sql, базы данных, Блог компании SkillFactory, оптимизация, планировщик, Программирование, производительность, Разработка веб-сайтов, Серверная оптимизация
В этом переводе к старту курса по Fullstack-разработке на PythonЧитать полностью »
Используем GPU для повышения производительности JavaScript
2021-05-06 в 9:55, admin, рубрики: cpu, gpgpu, gpu, GPU.js, javascript, Блог компании VDSina.ru, производительность, Разработка веб-сайтов
Мы, разработчики, всегда стремимся искать возможности повышения производительности приложений. Когда речь идёт о веб-приложениях, то улучшения обычно вносятся только в код.
Но думали ли вы об использовании мощи GPU для повышения производительности веб-приложений?
В этой статье я расскажу о библиотеке ускорения JavaScript под названием GPU.js, а также покажу вам, как повысить скорость сложных вычислений.
Что такое GPU.js и почему его стоит использовать?
Если вкратце, GPU.js — это библиотека ускорения JavaScript, которую можно использовать для любых стандартных вычислений на GPU при работе с JavaScript. Она поддерживает браузеры, Node.js и TypeScript.
Кроме повышения производительности если и множество других причин, по которым я рекомендую использовать GPU.js:
- В основе GPU.js лежит JavaScript, что позволяет использовать синтаксис JavaScript.
- Библиотека берёт на себя задачу автоматической транспиляции JavaScript на язык шейдеров и их компиляции.
- Если в устройстве отсутствует GPU, она может «откатиться» к обычному движку JavaScript. То есть вы ничего не потеряете, работая с GPU.js.
- GPU.js можно использовать и для параллельных вычислений. Кроме того, можно асинхронно выполнять множественные вычисления одновременно и на CPU, и на GPU.
Учитывая всё вышесказанное, я не вижу никаких причин не пользоваться GPU.js. Давайте узнаем, как его освоить.
Читать полностью »
Как мы устраняли ошибку Chrome, скрывавшуюся в коде со времён совместимости с Windows XP
2021-04-27 в 6:00, admin, рубрики: chromium, Google Chrome, Блог компании VDSina.ru, браузеры, производительность, трассировка, шрифты, эмодзи
Нам повезло, что так много людей использует в качестве браузера Chrome, и поэтому мы непрерывно повышаем его производительность. Но в таком сложном ПО, как Chrome, многие оптимизации скорости скрыты в местах, над которыми мы не работаем активно.
1%
Наши метрики показывают, что Chrome в среднем быстр, но временами может заметно притормаживать. Подобные страдания пользователей видны в 99-м перцентиле многих метрик, но невоспроизводимы, а поэтому с ними довольно сложно работать. Более глубокий анализ данных показывает, что «длинный хвост» производительности свойственен не 1% пользователей на медленных машинах, а множеству пользователей в 1% от общего времени.
Давайте поговорим об этом 1%. Читать полностью »
Люди подозревают, что технологии — отстой, потому что они на самом деле отстой
2021-04-05 в 12:50, admin, рубрики: usability, Блог компании НПП ИТЭЛМА, Научно-популярное, производительность, разработка под iOS, Разработка под MacOS
Джей Ситтер в своей статье "Люди подозревают, что технологии — отстой" пишет о людях, которые продолжают использовать технологии, несмотря на серьезные неприятности, такие как очень тусклый экран или постоянные всплывающие окна, и ничего не делают с этим. Он делает вывод:
Если бы мой экран был на 5% яркости или если бы я не мог использовать свой телефон, не нажимая «Отмена» каждые пять секунд, я бы тратил часы или дни на Google, пытаясь найти решение, если бы это было то, что мне нужно. То, что эти люди в основном просто мирились с проблемами, означает, что для них эти проблемы не могли быть заметно хуже, чем сама технология в своей основе.
Эти примеры немного экстремальны, но важно помнить, что они реальны. Это не преувеличение. Это происходило.
В обсуждениях в Твиттере люди продолжают отвечать, что этим пользователям следует:
- сделать что-нибудь с этим,
- искать замену,
- или просто не делать ничего.
И я бы согласился: если бы это был единичный случай, конечно, надо было бы что-то с этим сделать! Дело в том, что это происходит постоянно, каждый день, несколько раз в день, и один человек может посвятить этому лишь определенное количество времени. Поток мелких неприятностей настолько велик, что люди просто устали иметь с ними дело! И нет, лучшей альтернативы нет.
Чтобы доказать свою точку зрения, я решил записывать каждое прерванное действие в течение одного дня. Вот полный список, который я написал вчера, 24 сентября 2020 года:
Читать полностью »
Тест производительности PostgreSQL на AWS EC2-инстансах на ARM
2021-03-18 в 9:35, admin, рубрики: AWS, devops, postgresql, Администрирование баз данных, Блог компании Флант, производительностьПрим. перев.: в конце января Percona опубликовала результаты своего небольшого сравнения производительности для СУБД PostgreSQL, запущенной на x86- и ARM-инстансах AWS. Результаты получились интересными даже с учетом всех допущений, сделанных самими авторами и отмеченных комментаторами оригинальной статьи. А чтобы вы могли сделать собственные выводы, предлагаем вниманию перевод этого материала.
Мы отрендерили миллион страниц, чтобы понять, из-за чего тормозит веб
2020-12-30 в 9:17, admin, рубрики: java, Анализ и проектирование систем, высокая производительность, данные, производительность, Тестирование IT-систем, Тестирование веб-сервисовМы отрендерили 1 миллион самых популярных страниц веба, фиксируя все мыслимые метрики производительности, записывая все ошибки и замечая все запрошенные URL. Похоже, таким образом мы создали первый в мире набор данных, связывающий производительность, ошибки и использование библиотек в сети. В этой статье мы проанализируем, что наши данные могут сообщить о создании высокопроизводительных веб-сайтов.
- Посещён 1 миллион страниц
- Записано по 65 метрик каждой страницы
- Запрошен 21 миллион URL
- Зафиксировано 383 тысячи ошибок
- Сохранено 88 миллионов глобальных переменных
Можно ли превзойти наш анализ? Мы опубликовали наш набор данных на Kaggle, поэтому вы можете обработать данные самостоятельно.
Зачем рендерить миллион веб-страниц?
Сегодня распространено мнение о том, что веб почему-то стал более медленным и забагованным, чем 15 лет назад. Из-за постоянно растущей кучи JavaScript, фреймворков, веб-шрифтов и полифилов, мы съели все преимущества, которые даёт нам увеличение возможностей компьютеров, сетей и протоколов. По крайней мере, так утверждает молва. Мы хотели проверить, правда ли это на самом деле, а также найти общие факторы, которые становятся причиной торможения и поломок сайтов в 2020 году.
Общий план был простым: написать скрипт для веб-браузера, заставить его рендерить корневую страницу миллиона самых популярных доменов и зафиксировать все мыслимые метрики: время рендеринга, количество запросов, перерисовку, ошибки JavaScript, используемые библиотеки и т.п. Имея на руках все эти данные, мы могли бы начать задаваться вопросами о том, как один фактор корреллирует с другим. Какие факторы сильнее всего влияют на замедление рендеринга? Какие библиотеки увеличивают время до момента возможности взаимодействия со страницей (time-to-interactive)? Какие ошибки встречаются наиболее часто, и что их вызывает?
Читать полностью »