Почему приложение грузит CPU. Ложка дегтя в бочке с медом

Рассмотрев методы сжатия, объединения, кэширования и создания параллельных соединений, разумно было бы заняться следующим вопросом: Какая часть страницы должна загружаться вместе с основным HTML-файлом, а какая — только с внешними файлами?

Было собрано тестовое окружение в виде одной страницы, для которой применены различные оптимизационные техники (заодно было получено реальное ускорение для загрузки произвольной страницы и показано, как все эти техники реально влияют на скорость загрузки страницы).

Кроме того, были проведены теоретические выкладки для определения оптимального распределения загрузки по стадиям с учетом всех аспектов.

Реальная ситуация

Рис. 29. Диаграмма загрузки (неизмененного) сайта WebHiTech.ru

Основная идея вариации потока загрузки заключалась в создании минимального количества «белых мест» на диаграмме загрузки. Как видно из рис. 29, около 80% при загрузке страницы составляют простои соединений (естественно, что данный график не отражает реальную загрузку открытых в браузере каналов загрузки, однако, при уточнении картины ситуация практически не меняется). Параллельные загрузки начинаются только после прохождения «узкого места», которое заканчивается (в данном случае) после предзагрузки страницы — после CSS-файла.

Для оптимизации скорости загрузки нам нужно уменьшить число файлов (вертикальные стрелки), загружающихся параллельно, и «сдвинуть» их максимально влево (горизонтальная стрелка). Уменьшение «белых мест» (фактически, уменьшение простоя каналов загрузки), по идее, должно увеличить скорость загрузки за счет ее распараллеливания. Давайте посмотрим, действительно ли это так и как этого добиться.

Шаг первый: простая страница

Вначале бралась обычная страница, для которой использовалось только gzip-сжатие HTML-файла. Это самое простое, что может быть сделано для ускорения загрузки страницы. Данная оптимизация бралась за основу, с которой сравнивалось все остальное. Для тестов препарировалась главная страница конкурса WebHiTech (http://webhitech.ru/) с небольшим количеством дополнительных картинок (чтобы было больше внешних объектов, и размер страницы увеличивался).

В самом начале (head) страницы замеряется начальное время, а по событию window.onload (заметим, что только по нему, ибо только оно гарантирует, что вся страница целиком находится в клиентском браузере) — конечное, затем вычисляется разница. Но этот очень простой пример, перейдем к следующим шагам.

Шаг второй: уменьшаем изображения

Для начала минимизируем все исходные изображения (основные прикладные техники уже были освещены во второй главе). Получилось довольно забавно: суммарный размер страницы уменьшился на 8%, и скорость загрузки возросла на 8% (т.е. получилось пропорциональное ускорение).

Дополнительно с минимизацией картинок была уменьшена таблица стилей (через CSS Tidy) и сам HTML-файл (убраны лишние пробелы и переводы строк). Скриптов на странице не было, поэтому общее время загрузки изменилось не сильно. Но это еще не конец, и мы переходим к третьему шагу.

Шаг третий: все-в-одном

Можно использовать data:URI и внедрить все изображения в соответствующие HTML/CSS-файлы, уменьшив, таким образом, размер страницы (за счет gzip-сжатия, по большому счету, потому что таблица стилей перед этим не сжималась) еще на 15%, однако, время загрузки при этом уменьшилось всего на 4% (при включенном кэшировании, уменьшилось число запросов с 304-ответом). При загрузке страницы в первый раз улучшения гораздо более стабильны: 20%.

CSS-файл, естественно, тоже был включен в HTML, поэтому при загрузке всей страницы осуществлялся только один запрос к серверу (для отображения целой страницы с парой десяткой объектов).

Шаг четвертый: нарезаем поток

Можно попробовать распределить первоначальный монолитный файла на несколько (5- 10) равных частей, которые бы затем собирались и внедрялись прямо в document.body.innerHTML. Т.е. сам начальный HTML-файл очень мал (фактически, содержит только предзагрузчик) и загружается весьма быстро, а после этого стартует параллельная загрузка еще множества одинаковых файлов, которые используют канал загрузки максимально плотно.

Однако, как показали исследования, издержки на XHR-запросы и сборку innerHTML на клиенте сильно превосходят выигрыш от такого распараллеливания. В итоге, страница будет загружаться в 2-5 раз дольше, размер при этом изменяется не сильно.

Можно попробовать использовать вместо XHR-запросов классические iframe, чтобы избежать части издержек. Это помогает, но не сильно. Страница все равно будет загружаться в 2-3 раза дольше, чем хотелось бы.

И немного к вопросу применения фреймов: очень часто наиболее используемые части сайта делают именно на них, чтобы снизить размер передаваемых данных. Как уже упомянуто выше, основная часть задержек происходит из-за большого количества внешних объектов на странице, а не из-за размера внешних объектов. Поэтому на данный момент эта технология далеко не так актуальна, как в 90-е годы прошлого столетия.

Также стоит упомянуть, что при использовании iframe для навигации по сайту встает проблема обновления этой самой навигации (например, если мы хотим выделить какой-то пункт меню как активный). Корректное решение этой проблемы требует от пользователя включенного JavaScript, и оно довольно нетривиально с технической стороны. В общем, если без фреймов можно обойтись при проектировании сайта — значит, их не нужно использовать.

Шаг пятый: алгоритмическое кэширование

Проанализировав ситуацию с первыми тремя шагами, мы видим, что часть ускорения может быть достигнута, если предоставить браузеру возможность самому загружать внешние файлы как отдельные объекты, а не как JSON-код, который нужно как-то преобразовать. Дополнительно к этому всплывают аспекты кэширования: ведь быстрее загрузить половину страницы, а для второй половины проверить запросами со статус- кодами 304, что объекты не изменились. Загрузка всей страницы клиентом в первый раз в данном случае будет немного медленнее (естественно, решение по этому поводу будет зависеть от числа постоянных пользователей ресурса).

В результате удалось уменьшить время загрузки еще на 5%, итоговое ускорение (в случае полного кэша) достигло 20%, размер страницы при этом уменьшился на 21%. Возможно вынесение не более 50% от размера страницы в загрузку внешних объектов, при этом объекты должны быть примерно равного размера (расхождение не более 20%). В таком случае скорость загрузки страницы для пользователей с полным кэшем будет наибольшей. Если страница оптимизируется под пользователей с пустым кэшем, то наилучший результат достигается только при включении всех внешних файлов в исходный HTML.

Итоговая таблица

Ниже приведены все результаты оптимизации для отдельной взятой страницы. Загрузка тестировалась на соединении 100 Кб/с, общее число первоначальных объектов: 23.

Номер шага

Описание

Общий размер (кб)

Время загрузки (мс)
1 Обычная страница. Ничего не сжато (только html отдается через gzip) 63 117
2 HTML/CSS файлы и картинки минимизированы 58 108
3 Один-единственный файл. Картинки вставлены через data:URI 49 104
4 HTML-файл параллельно загружает 6 частей с данными и собирает их на клиенте 49 233
4.5 HTML-файл загружает 4 iframe 49 205
5 Вариант #3, только JPEG-изображения (примерно одинаковые по размеру) вынесены в файлы и загружаются через (new Image()).src в head странице 49 98

Таблица 5. Различные способы параллельной загрузки объектов на странице

Шаг шестой: балансируем стадии загрузки

Итак, как нам лучше всего балансировать загрузку страницы между ее стадиями? Где та «золотая середина», обеспечивающая оптимум загрузки? Начнем с предположения, что у нас уже выполнены все советы по уменьшению объема данных. Это можно сделать всегда, это достаточно просто (в большинстве случаев нужны лишь небольшие изменения в конфигурации сервера). Также предположим, что статика отдается уже с кэширующими заголовками (чтобы возвращать 304-ответы в том случае, если ресурсный файл физически не изменился с момента последнего посещения).

Что дальше? Дальнейшие действия зависят от структуры внешних файлов. При большом (больше двух) числе файлов, подключаемых в страницы, необходимо объединить файлы стилей и файлы скриптов. Ускорение предзагрузки страницы будет налицо.

Если объем скриптов даже после сжатия достаточно велик (больше 10 Кб), то стоит их подключить перед закрывающим , либо вообще загружать по комбинированному событию window.onload (динамической загрузке скриптов посвящено начало седьмой главы). Тут мы, фактически, переносим часть загрузки из второй стадии в четвертую, ускоряется лишь «визуальная» загрузка страницы.

Общее количество картинок должно быть минимальным. Однако тут тоже очень важно равномерно распределить их объем по третьей стадии загрузки. Довольно часто одно изображение в 50-100 Кб тормозит завершение загрузки, разбиение его на 3-4 составляющие способно ускорить общий процесс. Поэтому при использовании большого количества фоновых изображений лучше разбивать их на блоки по 10-20, которые будут загружаться параллельно.

Шаг седьмой: балансируем кэширование

Если все же на странице присутствует больше 10 внешних объектов в третьей стадии (картинок и различных мультимедийных файлов), тут уже стоит вводить дополнительный хост для увеличения числа параллельных потоков. В этом случае издержки на DNS-запрос окупятся снижением среднего времени установления соединения. 3 хоста стоит вводить уже после 20 объектов, и т.д. Всего не более 4 (как показало исследование рабочей группы Yahoo! после 4 хостов издержки, скорее, возрастут, чем снизятся).

Вопрос о том, сколько объема страницы включать в сам HTML-файл (кода в виде CSS, JavaScript или data:URI), а сколько оставлять на внешних объектах, решается очень просто. Баланс в данном случае примерно равен соотношению числа постоянных и единовременных посещений. Например, если 70% пользователей заходят на сайт в течение недели, то примерно 70% страницы должно находиться во внешних объектах и только 30% — в HTML-документе.

Когда страницу должны увидеть только один раз, логично будет включить все в саму страницу. Однако тут уже вступают в силу психологические моменты. Если у среднего пользователя страница при этом будет загружаться больше 3-4 секунд (учитывая время на DNS-запрос и соединение с сервером), то будет необходимо разбиение на две части: первоначальная версия, которая отобразится достаточно быстро, и остальная часть страницы.

Очень важно понимать, какая стадия загрузки при этом оптимизируется и что видит реальный пользователь (с чистым кэшем и, может быть, небыстрым каналом). Подробнее об анализе процесса загрузки страницы на конкретных примерах рассказывается в восьмой главе.

Заключение

Вот так, на примере обычной страницы (уже достаточно хорошо сделанной, стоит отметить) мы добились ускорения ее загрузки еще на 15-20% (и это без учета применения gzip-сжатия для HTML, которое в данном случае дает примерно 10% от общей скорости). Наиболее важные методы уже приведены выше, сейчас лишь можно упомянуть, что при оптимизации скорости работы страницы лучше всегда полагаться на внутренние механизмы браузера, а не пытаться их эмулировать на JavaScript (в данном случае речь идет об искусственной «нарезке» потока). Может быть, в будущем клиентские машины станут достаточно мощными (или же JavaScript-движки — лучше оптимизированными), чтобы такие методы заработали. Сейчас же выбор один — алгоритмическое кэширование.

Суть проблемы.

Ваше запущенное приложение в какой то момент начинает активно грузить CPU, вас зовёт тестер и просит починить это!

Какие обычные действия программистов в таком случае?

  • Просят локализовать, если получается, то решить проблему вопрос времени.
  • Начинается добавление логов, счетчиков проходов и тому подобного. Все отдается тестеру или заказчику с требованием воспроизвести и вернуть лог на анализ. Хорошо если воспроизвести удастся и все станет ясно.
  • Предположить время, когда "все работало" и по изменениями в системе контроля версий искать возможные причины.


Как проще поступить вэтом случае?

означает, что какой то поток(и) обработки данных проснулся\запустился, и стал активно выполнять свою работу или иногда просто зациклился. Узнав стек выполнения в момент нагрузки, можно с высокой долей вероятности понять причину такого поведения.

Как же его можно узнать, ведь мы не находимся под отладчиком ?Лично я пользуюсь утилитой Process Explorer дающая возможность увидеть список потоков и их стек . Программа установки не требует.

Для демонстрации я запустил свое приложение с именем процесса "Qocr.Application.Wpf.exe ", в которое добавил фейковый код бесконечного цикла . Теперь давайте найдём причину загрузки ядра без отладчика . Для этого я иду в ствойства процесса, далее:

  1. Переходим на вкладку Threads и видим, что имеется 1 поток, который грузит на 16% CPU .
  2. Выделяем этот поток и жмем Stack, открылось окно "Stack for thread ID ".
  3. В окне видим, что наш поток был создан тут Qocr.Application.Wpf.exe!<>c. b__36_1+0x3a и в данный момент вызывает GetDirectories из метода InitLanguages().

Продемонстрирую действия выше на изображении со стрелками:

Открыв исходный код программы и перейдя к методу InitLanguages можно увидеть мой фейковый код. Зная эту информацию, а именно место отстановки, можно уже принимать меры.

Код стека (из примера выше) вызывающий бесконечный цикл (Можно проверить):

Private void InitLanguages() { new Thread (() => { while (true ) { var dir = Directory .GetDirectories(@"C:\" ); } ; }).Start(); }

Ложка дегтя в бочке с медом.

Два момента, которые стоит знать, если решите воспользоваться способом выше:
  1. Потоки созданные CLR (созданные в коде .NET приложения) после останова не продолжают выполнение. В результате чего поток останавливается и остается висеть до перезапуска программы.
  2. Если стек исполнения не содержит полезной информации, то стоит проделать остановку и просмотр стека несколько раз. Вероятность наткнуться на место зацикливания очень велика.

Состояния потоков и планирование их выполнения


Для каждого созданного потока в системе предусматриваются три возможных его состояния:

  • состояние выполнения, когда код потока выполняется процессором; на однопроцессорных платформах в этом состоянии в каждый момент времени может находиться только один поток;
  • состояние готовности к выполнению, когда поток готов продолжать свою работу и ждет освобождения ЦП;
  • состояние ожидания наступления некоторого события; в этом случае поток не претендует на время ЦП, пока не наступит определенное событие (завершение операции ввода/вывода, освобождение необходимого потоку занятого ресурса, сигнала от другого потока); часто такие потоки называют блокированными.
Изменение состояния потока происходит в результате соответствующих действий. Удобно для этих целей использовать следующую диаграмму состояний и переходов.

Переходы между состояниями можно описать следующим образом:

  • «готовность» → «выполнение»: система в соответствии с алгоритмом планирования выбирает для выполнения текущий поток, предоставляя ему ЦП
  • «выполнение» → «готовность»: поток готов продолжать свою работу, но система принимает решение прервать его выполнение; чаще всего это происходит по следующим двум причинам:
    • завершается выделенное потоку время владения процессором;
    • в числе готовых к выполнению появляется более приоритетный поток по сравнению с текущим;
  • «выполнение» → «ожидание»: дальнейшее исполнение кода текущего активного потока невозможно без наступления некоторого события, и поэтому активный поток прерывает свое выполнение и переводится системой в состояние ожидания (блокируется);
  • «ожиданием» → «готовность»: в системе происходит некоторое событие, наступление которого ожидает один из блокированных потоков, и поэтому система переводит этот поток в состояние готовности (разблокирует), после чего он будет учитываться системой при планировании порядка предоставления ЦП;
  • наконец, поток может нормально или аварийно завершить свое выполнение, после чего система удаляет его дескриптор из своей внутренней структуры, и тем самым поток перестает существовать.
В состояниях готовности и ожидания может находиться несколько потоков, поэтому система создает для хранения их дескрипторов отдельные списковые структуры. Организация этих списков зависит от тех принципов, которые положены в основу планирования потоков для данной ОС.

Цель планирования потоков вполне очевидна - определение порядка выполнения потоков в условиях внешней или внутренней многозадачности. Однако способы достижения этой цели существенно зависят от типа ОС. Рассмотрим сначала принципы планирования для универсальных ОС. Для таких ОС нельзя заранее предсказать, сколько и какие потоки будут запущены в каждый момент времени и в каких состояниях они будут находиться. Поэтому планирование должно выполняться динамически на основе сбора и анализа информации о текущем состоянии вычислительной системы.

Для этого в состав ОС включается модуль-планировщик, реализующий выбранные алгоритмы планирования. Поскольку этот модуль представляет собой программный код, то для решения своих задач планировщик должен на некоторое время забирать ЦП. Отсюда следует, что алгоритмы планирования должны быть максимально простыми, иначе возникает опасность, что система будет тратить недопустимо большое время на решение своих внутренних задач, а на выполнение прикладных программ времени не останется.

Кроме вычислительной простоты, алгоритмы планирования должны обладать следующими общими свойствами:

  • обеспечение максимально возможной загрузки ЦП;
  • обеспечение равномерной загрузки ресурсов вычислительной системы;
  • обеспечение справедливого обслуживания всех процессов и потоков;
  • минимизация времени отклика для интерактивных процессов.
За время существования ОС было предложено и реализовано несколько принципов управления потоками. В настоящее время большинство универсальных ОС используют метод вытесняющей многозадачности (preemptive multitasking), который тоже имеет несколько разновидностей. В основе метода лежат два важнейших и достаточно понятных принципа: квантование времени ЦП и приоритеты потоков.

Квантование означает, что каждому потоку система выделяет определенный интервал времени (квант), в течение которого процессор потенциально может выполнять код этого потока. По завершении выделенного кванта планировщик принудительно переключает процессор на выполнение другого готового потока (если, конечно, такой есть), переводя старый активный поток в состояние готовности. Это гарантирует, что ни один поток не захватит ЦП на непозволительно большое время (как было в более ранних системах с так называемой невытесняющей или кооперативной многозадачностью). Конечно, выделенный квант поток может и не использовать до конца, если в процессе своего выполнения он нормально или аварийно завершится, или потребует наступления некоторого события, или будет прерван системой.

Для эффективной работы ОС большое значение имеет выбор величины кванта. Очень маленькие значения кванта приводят к частым переключениям ЦП, что повышает непроизводительные расходы из-за необходимости постоянного сохранения контекста прерываемого потока и загрузки контекста активизируемого потока. Наоборот, большие значения кванта уменьшают иллюзию одновременного выполнения нескольких приложений. Некоторые планировщики умеют изменять кванты в определенных пределах, увеличивая их для тех потоков, которые не используют до конца выделенное время, например, из-за частых обращений к операциям ввода/вывода. Типичный диапазон изменения кванта – от 10 до 50 миллисекунд. При этом необходимо учитывать все возрастающие скорости работы современных процессоров: за 10 миллисекунд (т.е. за 1/100 секунды) процессор успеет выполнить около 10 млн. элементарных команд.

Можно связать величину кванта с приоритетом потока. Приоритет определяет важность потока и влияет на частоту запуска потока и, возможно, на величину выделяемого кванта. Интуитивно понятно, что потоки могут иметь разную степень важности: системные – более высокую (иначе ОС не сможет решать свои задачи), прикладные – менее высокую. Многие ОС позволяют группировать потоки по их важности, выделяя три группы, или класса:

  • потоки реального времени с максимально высоким уровнем приоритета;
  • системные потоки с меньшим уровнем приоритета;
  • прикладные потоки с самым низким приоритетом.
Внутри каждой группы выделяется свой диапазон возможных значений приоритетов, причем эти диапазоны между собой не пересекаются, т.е. максимально возможный приоритет прикладного потока всегда будет строго меньше минимально возможного приоритета для системных потоков. Внутри каждой группы могут использоваться разные алгоритмы управления приоритетами.

Если приоритет потока может меняться системой, то такие приоритеты называют динамическими, иначе – фиксированными. Конечно, реализация фиксированных приоритетов гораздо проще, тогда как динамические приоритеты позволяют реализовать более справедливое распределение процессорного времени. Например, потоки, интенсивно использующие внешние устройства, очень часто блокируются до завершения выделенного кванта времени, т.е. не используют эти кванты полностью. Справедливо при разблокировании таких потоков дать им более высокий приоритет для быстрой активации, что обеспечивает большую загрузку относительно медленных внешних устройств. С другой стороны, если поток полностью расходует выделенный квант, система может после его приостановки уменьшить приоритет. Тем самым, более высокие приоритеты получают более короткие потоки, быстро освобождающие процессор, и следовательно, достигается более равномерная загрузка вычислительной системы в целом.

Довольно интересной и часто используемой разновидностью приоритетов являются так называемые абсолютные приоритеты: как только среди готовых потоков появляется поток, приоритет которого выше, чем приоритет текущего активного потока, этот активный поток досрочно прерывается с передачей процессора более приоритетному потоку.

Для реализации приоритетного обслуживания ОС должна создавать и поддерживать набор приоритетных очередей. Для каждого возможного значения приоритета создается своя очередь, в которую потоки (в виде своих дескрипторов) помещаются строго в соответствии с очередностью. Планировщик просматривает эти очереди по порядку следования приоритетов и выбирает для выполнения первый поток в самой приоритетной непустой очереди. Отсюда следует, что потоки с меньшими приоритетами будут выполняться, только если пусты все более приоритетные очереди. Если допускается изменение приоритета, то планировщик должен уметь перемещать поток в другую очередь в соответствии с новым значением приоритета.

Схематично массив приоритетных очередей представлен на следующем рисунке, где для удобства более приоритетные потоки собраны в левой части массива, менее приоритетные – в правой, а сами приоритеты изменяются от 1 (максимум) до n (минимум). Условное обозначение «поток i.2» показывает, что данный поток имеет приоритет i и стоит вторым по порядку в своей очереди.

Для изменения приоритета и, возможно, кванта времени планировщику необходима следующая информация: базовая величина приоритета и кванта, время ожидания в очереди, накопленное время выполнения, интенсивность обращения к операциям ввода/вывода. Вся эта информация должна сохраняться в соответствующих структурах данных.

В итоге, планировщик включается в работу при возникновении одного из следующих событий:

  • завершение кванта времени для текущего активного потока (сигнал от системного таймера);
  • нормальное завершение кода текущего активного потока;
  • аварийное завершение кода текущего активного потока;
  • запрос активным потоком занятого системного ресурса;
  • появление среди готовых потоков более приоритетного потока.
При этом запускается код планировщика, который просматривает приоритетные очереди и выбирает наиболее приоритетный поток. После этого происходит собственно само переключение потоков:
  • формируется контекст прерываемого потока;
    • с помощью контекста вновь активизируемого потока восстанавливается необходимое состояние вычислительной системы, в частности, загружаются необходимые значения во все регистры процессора;
  • поскольку в регистр-счетчик команд из контекста заносится адрес очередной подлежащей выполнению команды активизируемого потока, то процессор переходит к выполнению кода нового потока точно с того места, где оно было прервано.
Планирование потоков в системах реального времени строится на других принципах. Поскольку для подобных систем наиболее важным показателем является скорость работы, то планирование выполняется статически. Для этого заранее строится так называемая таблица переключений, с помощью которой в зависимости от текущего состояния вычислительного процесса быстро и однозначно определяется запускаемый в данный момент поток.

6 ответов

Вам нужно будет показать код основного потока, чтобы указать, как он уведомляется о том, что он загружен. Скорее всего, проблема блокировки. Это действительно хороший пример использования асинхронного ввода-вывода вместо потоков, если вы можете использовать его в своем основном цикле. Если вам больше не нужно использовать условия или события. Один из них, чтобы вызвать поток чтения файла, который есть, и другой, чтобы сигнализировать основному потоку, был загружен файл.

Изменить: Хорошо, так что это игра, и вы проводите опрос, чтобы посмотреть, загружен ли файл как часть цикла рендеринга. Вот что я хотел бы попробовать: используйте ReadFileEx для запуска перекрытого чтения. Это не будет заблокировано. Затем в вашем основном цикле вы можете проверить, выполняется ли чтение, используя одну из функций Wait с нулевым таймаутом. Это также не будет блокировать.

если вы можете рассмотреть варианты с открытым исходным кодом, у Java есть блокирующая очередь [ссылка ], как и Python [ссылка . Это уменьшит ваш код до (очередь здесь привязана к load_fcn, т.е. С использованием закрытия)

Def load_fcn(): while True: queue.get().loadFileAndMemcpy() threading.Thread(target=load_fcn).start()

Даже если вы, возможно, не должны их использовать, потоки python 3.0 имеют функцию _stop(), а потоки python2.0 имеют функцию _Thread__stop. Вы также можете записать значение "Нет" в очередь и проверить load_fcn().

Кроме того, поиск stackoverflow для " gui" и "[субъективный] ", если хотите.

Основываясь на информации, присутствующей в этой точке, я предполагаю, что что-то в обработчике загрузки файла взаимодействует с вашим основным циклом. Я не знаю библиотеки, но на основании вашего описания обработчик файлов делает что-то в следующих строках:

  • Загрузка необработанных двоичных данных для файла 20 тыс.
  • Интерпретировать 20k как PNG файл
  • Загрузка в структуру, представляющую изображение с разрешением 2048 × 2048 пикселей

Следующие возможности напоминают библиотеки, которые вы используете для достижения следующих шагов:

  • Может ли быть, что распределение памяти для несжатых данных изображения удерживает блокировку, которая требуется основному потоку для любых выполняемых ею графических/интерактивных операций?
  • Может ли быть, что вызов, который отвечает за перевод PNG-данных в пиксели, фактически содержит блокировку библиотеки нижнего уровня, которая неблагоприятно взаимодействует с вашим основным потоком?

Лучший способ получить дополнительную информацию - попытаться смоделировать активность обработчика загрузчика файлов без использования текущего кода в нем... написать процедуру самостоятельно, которая выделяет правильный размер блока памяти и выполняет некоторую обработку который превращает 20k исходных данных в структуру размером целевого блока... затем добавляет к нему еще одну логику за раз, пока вы не сузились, когда производительность падает, чтобы изолировать виновника.

Я бы написал этот цикл таким образом, за исключением блокировки разблокировки, которая могла бы быть испорчена: P:

Void fileLoadThreadFunc(void *arglist) { while(true) { loadObj *obj = NULL; // protect all access to the vector s_mutex.lock(); if(s_filesToLoad.size() != 0) { obj = s_filesToLoad; s_filesToLoad.erase(s_filesToLoad.begin()); } s_mutex.unlock(); if(obj != NULL) obj->loadFileAndMemcpy(); else Sleep(10); } }

Не уверен в вашей конкретной проблеме, но вы действительно должны мьютекс-защищать вызов по размеру.

Void fileLoadThreadFunc(void *arglist) { while (true) { s_mutex.lock(); while (s_filesToLoad.size() == 0) { s_mutex.unlock(); Sleep(10); s_mutex.lock(); } loadObj *obj = s_filesToLoad; s_filesToLoad.erase(s_filesToLoad.begin()); s_mutex.unlock(); obj->loadFileAndMemcpy(); } }

Теперь, исследуя вашу конкретную проблему, я не вижу ничего плохого в коде, который вы предоставили. Основной поток и поток загрузчика файлов должны с радостью работать бок о бок, если этот мьютекс является единственным конкурентом между ними.

Я говорю, что, поскольку в стандартной библиотеке могут присутствовать другие точки состязания, которые не отображаются вашим примером кода.