1. Не потокобезопасно, причем существование общего кэша не очевидно из интерфейса библиотеки.
2. Указание имени модуля рядом с именем процедуры, по моим ощущуениям, не совсем C++ style — избыточный runtime overhead. Если используются несколько процедур из одного модуля, то имя модуля все равно будет задаваться переменной или константой, так почему бы эту переменную не сделать схожей с ntmodule? Таким образом убирается поиск в кэше и добавляется управление временем жизни хэндла.
Любопытно было бы заменить в этой задаче массив интов на массив структур и сортировать по одному из полей. В C++ влияние вполне предсказуемое, а вот не будет ли это катастрофой в C#? (просто предположение — я в C# вообще никак)
Нет, 13 секунд простоя на каждые 100 млн объектов для меня вообще не показатель. Объяснить почему или догадаешься?
Пример системы (взят с потолка): в malloc/free тратится 5% времени, из всех malloc/free 50% более-менее можно переделать на placement new/delete. Итого 2.3% экономии. И куча проблем с отладкой. «Сумасшедший прирост производительности», однако!
поставят msvcr120.dll:malloc на колени из-за мьютекса
У меня было впечатление, что CRT использует напрямую системный heap, который реализован довольно прилично в Win7. Меня TBB malloc как-то особо не впечатлил. Может для WinXP имеет смысл, так как там системный heap тупее.
Вообще-то я имел в виду сравнение чуть более комплексных задач. Например, упомянутые в статье записи SQL, где сама запись выделяется в куче, а поля — в буфере.
Но даже на таком синтетическом тесте получается интересный результат. Практически ничего (placement new) сравнивается со сложным алгоритмом (полномасштабный heap с thread safety и т.д.) и получется разница на один порядок. 10 раз, Карл!
Вот теперь читатель статьи может прикинуть, стоит ли геморрой выделки.
Вопрос по реализации: при рисовании чертежа используется какое-то аппаратное ускорение и какое? GPU, вроде, сложно заставить нормальный antialiasing делать? Вобщем, интересно, как сделана быстрая и качественная 2D графика.
Пока в статье нет сравнения производительности предложенного примера в вариантах с placement new и с достаточно современным memory manager, эта статья скорее вредна, чем полезна.
1. 9 reinterpret_cast'ов в такого рода библиотечке — это даже не C++11, это все C++100500
2. Не уверен, но похоже, что только char нормально поддерживается.
3. Почему codepoint имеет тип size_t?
4. То, что parse принимает стрим или стандартный basic_string, выглядит излишним ограничением. Почему не пара итераторов?
5. Одно из многих возможных движений в направлении hardcore C++ — сделать JSON парсер отдельным темплейтным компонентом, чтобы предложенная схема хранения могла быть заменена на более подходящую пользователю.
примером того, что современные технологии могут не только упростить жизнь, но и осложнить её
Это как? Пришли белые люди, запретили исконо-посконую теплую ламповую бенгальскую письменность и заставили пользоваться расистским юникодом и твиттером? Не нравится — создайте свой юникод с ♠ и ☃.
2. Указание имени модуля рядом с именем процедуры, по моим ощущуениям, не совсем C++ style — избыточный runtime overhead. Если используются несколько процедур из одного модуля, то имя модуля все равно будет задаваться переменной или константой, так почему бы эту переменную не сделать схожей с ntmodule? Таким образом убирается поиск в кэше и добавляется управление временем жизни хэндла.
Нам же платят за то, что мы пишем код, а не за то, что мы не пишем код.
Пример системы (взят с потолка): в malloc/free тратится 5% времени, из всех malloc/free 50% более-менее можно переделать на placement new/delete. Итого 2.3% экономии. И куча проблем с отладкой. «Сумасшедший прирост производительности», однако!
У меня было впечатление, что CRT использует напрямую системный heap, который реализован довольно прилично в Win7. Меня TBB malloc как-то особо не впечатлил. Может для WinXP имеет смысл, так как там системный heap тупее.
Но даже на таком синтетическом тесте получается интересный результат. Практически ничего (placement new) сравнивается со сложным алгоритмом (полномасштабный heap с thread safety и т.д.) и получется разница на один порядок. 10 раз, Карл!
Вот теперь читатель статьи может прикинуть, стоит ли геморрой выделки.
2. Не уверен, но похоже, что только char нормально поддерживается.
3. Почему codepoint имеет тип size_t?
4. То, что parse принимает стрим или стандартный basic_string, выглядит излишним ограничением. Почему не пара итераторов?
5. Одно из многих возможных движений в направлении hardcore C++ — сделать JSON парсер отдельным темплейтным компонентом, чтобы предложенная схема хранения могла быть заменена на более подходящую пользователю.
Это как? Пришли белые люди, запретили исконо-посконую теплую ламповую бенгальскую письменность и заставили пользоваться расистским юникодом и твиттером? Не нравится — создайте свой юникод с ♠ и ☃.