с синхронизацией?
Чтобы убедиться, что именно из-за этого тормоза в твоём приложении
Если убрать синхронизацию и не совершать никаких действий, которые приведут к ошибкам по памяти, то тот же самый код работает в 1.5 раза быстрее. Вывод: замедление именно из-за синхронизации. Возможно стоит чекнуть в профайлере, чтобы найти другие узкие места
Запускаешь под отладчиком приложение, ждёшь, пока оно не выйдет на активную фазу обработки данных, и скажем раз в 10 секунд нажимаешь break. И так раз 10-20. Если у тебя 80% случаев все потоки кроме одного висят на мьютексе, то плохо, мьютекс мешает. Если картина другая, то ситуация получше
Разве это тот же код, если "не совершать действий, которые..."?
1.5 раза - это мало.
) И с синхронизацией и без не совершать этих действий для достоверности эксперимента
Очень возможно, что дело не в мьютексах. Вот если будет разница на несколько порядков, ну, хотя бы на один, тогда да, можно бороться с мьютексом.
Это совсем не показательный эксперимент, так как в продакшне приложение делает совершенно другие действия Соответственно и поведение может поменяться
Ну и на самом деле без синхронизации код твой просто будет невалидный, и время его выполнения нельзя ни с чем сравнивать
Там достаточно редкие события, когда одновременно один и тот же контейнер читают несколько потоков, думаю, дело в этом
Ну ок, проведи эксперимент с дебагером как я описал... Или профайлером пройдись.
Так вот, из-за того, что это события редкие, приложение какое-то время может работать и изменять данные без синхронизации порой достаточно долго, но, естественно, никто не знает, когда и что сломается в этом случае
Иначе ты будешь биться не с теми ветряными мельницами...
А сколько у тебя потоков?
1 на запись 1-3 на чтение
Просто 1.5 раза разницы между параллельной обработкой и последовательной - это ничто, ноль
Всё равно жалко(
Нет, не жалко
Обсуждают сегодня