CS>30 файлов по 2k каждый, т.е. 60k данных за 14s это про что вообще? Ты ничего не перепутал?

Сори не заходил сюда. Перепутал да.

Дело оказалось не в сериализации а в:

struct base_item {
  boost::uuid m_id;
  base_item() : m_id(boost::uuids::random_generator()()) {} 
};

Что на маке в силу реализации random_generator() приводило к тормозам (~14s Win против ~86s Mac).

Т.е. сперва создавался потомок base_item а потом к нему применялась десериализация, что приводило к излишней инициализации m_id т.к. она всеравно тут же "десериализировалась".
Во общем переписывание процедуры десериализации и введение специального способа конструирования объектов для этого, проблему решило.

Есть ли способ ускорить десериализацию построенную на subj?

По сути при десериализации есть много мелких операций (~400) десериализации значений типа unsigned int.
Хотя если брать суммарный объем данных (размер файла) из которых выполняется десериализация то он в среднем не больше 2kb.
И таких файлов не так и много около 30-ти штук.
И что самое неприятное, проблема проявляется только под Mac OS X, под Windows скорость работы вполне нормальная.

Что было уже сделано:
1) Переделка на memory_device, т.е. файл предварительно весь файл читается в буффер, на буфер натравляется memory_device + boost::iostreams и вся десериализация происходит над данными в памяти.
По показателям производительности (замерялось в debug):
Windows: ~14s
Mac OSX: ~86s

2) Пралельная десериализация. Т.е. запускается boost::thread::hardware_concurrency() * 2 -потоков и в каждом происходит десериализация.
Тут по показателям производительности вообще странные результаты (замерялось в debug):
Windows: ~4s
Mac OSX: ~105s

Т.е. под OSX она стала еще больше а под Windows еще меньше (как и ожидалось).

Приложение под OSX собирается clang-ом c ключами: -std=c++11 -O2 -msse2 -ffp-contract=fast

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

Здравствуйте, nen777w, Вы писали:

N>По показателям производительности (замерялось в debug):

Почему debug?
Какой компилятор на Windows?

N>Приложение под OSX собирается clang-ом c ключами: -std=c++11 -O2 -msse2 -ffp-contract=fast

Для начала можно добавить -DNDEBUG и вместо O2 поставить O3.
Плюс запустить под чем-то типа callgrind.

EP>Почему debug?
Потому что OSX все равно в релизе очень намного уступает Windows.

EP>Какой компилятор на Windows?
MSVC 2012

N>>Приложение под OSX собирается clang-ом c ключами: -std=c++11 -O2 -msse2 -ffp-contract=fast
EP>Для начала можно добавить -DNDEBUG и вместо O2 поставить O3.
O3 не пробовал, не думаю что это что то даст, но попробую.

EP>Плюс запустить под чем-то типа callgrind.
Померяю, но когда то под VTune смотрел (под Windows правда) самый большой тормоз boost::serialize и его дремучий стек на каждую операцию.

Мне больше интересно почему OSX так сильно уступает Windows (да еще и с регрессией в многопоточном режиме).
Компилировал кстати приложение под Linux (release), т.е. замеров не делал, но по скорости (чисто на глаз) оно работает точно как и под Windows.

Здравствуйте, nen777w, Вы писали:

N>Есть ли способ ускорить десериализацию построенную на subj?

N>По сути при десериализации есть много мелких операций (~400) десериализации значений типа unsigned int.
N>Хотя если брать суммарный объем данных (размер файла) из которых выполняется десериализация то он в среднем не больше 2kb.
N>И таких файлов не так и много около 30-ти штук.
N>И что самое неприятное, проблема проявляется только под Mac OS X, под Windows скорость работы вполне нормальная.

Под Mac код 64битный, а под windows 32битная сборка или 64битная?

Здравствуйте, nen777w, Вы писали:

30 файлов по 2k каждый, т.е. 60k данных за 14s это про что вообще? Ты ничего не перепутал?

Здравствуйте, nen777w, Вы писали:

N>Есть ли способ ускорить десериализацию построенную на subj?

Nixman писал свою сериализацию, кажется YAS называется.
Насколько помню, у него получилось очень значительное ускорение, и кажется совместимость бинарная есть

Здравствуйте, Evgeniy Skvortsov, Вы писали:

ES>Nixman писал свою сериализацию, кажется YAS называется.
ES>Насколько помню, у него получилось очень значительное ускорение, и кажется совместимость бинарная есть

По-моему, бинарной совместимости нет, но скорость выше да, опережает остальных конкурентов: https://github.com/STEllAR-GROUP/cpp-serializers/pull/2

Здравствуйте, Evgeniy Skvortsov, Вы писали:

ES>... кажется совместимость бинарная есть
нет, хотя была такая идея. и реализовать вроде как не сложно, но надобности небыло...