Сборник шаблонов тестов [дубликат]
Ваше решение подвержено ошибкам. Вы в основном реализовали блокировку с двойным проверкой ( http://en.wikipedia.org/wiki/Double-checked_locking ), которая может быть очень опасной.
Лучшее решение чтобы либо вводить изоляцию потоков, когда только один поток когда-либо обращается к файлу, и делает это, читая из очереди, по которой запросы на чтение или запись помещаются другими потоками (и, конечно, очередь защищена взаимоисключающим доступом по потокам) или где потоки синхронизируются либо с помощью устройств синхронизации (секции lock, либо mutotes, либо), либо с использованием какой-либо другой логики доступа к файлу (например, System.IO.FileShare).
4 ответа
Я работаю с 2008 года в библиотеке, которая сильно использует метапрограммирование шаблонов. Существует реальная потребность в лучших инструментах или подходах для понимания того, что потребляет наибольшее время компиляции.
Единственный метод, о котором я знаю, - это подход с разделением и завоеванием, либо разделяя код на разные файлы, и комментируя тела определений шаблонов или путем обертывания ваших экземпляров шаблонов в макросах #define и временного переопределения этих макросов, чтобы ничего не делать. Затем вы можете перекомпилировать проект с помощью различных экземпляров и без ограничений.
Кстати, просто разделение одного и того же кода на большее, более мелкие файлы могут ускорить его компиляцию. Я не просто говорю о возможности параллельной компиляции - даже в серийном режиме, я заметил, что она все еще быстрее. Я наблюдал этот эффект в gcc как при компиляции моей библиотеки, так и при компиляции парсеров Boost Spirit. Моя теория заключается в том, что некоторая часть разрешения символа, разрешения перегрузки, SFINAE или кода ввода типа в gcc имеет сложность O (n log n) или даже O (n ^ 2) в отношении количества определений типов или символов в игре в исполнительном блоке.
В конечном счете вам нужно тщательно изучить ваши шаблоны и отделить то, что действительно зависит от информации о типе от того, чего нет, и использовать стирание стилей и виртуальные функции, которые возможно на части код, который фактически не требует типов шаблонов. Вам нужно получить материал из заголовков и в файлы cpp, если эту часть кода можно переместить. В идеальном мире компилятор должен уметь это понять сам по себе - вам не придется вручную перемещать этот код, чтобы его нянчить, но это современное состояние с компиляторами, которые у нас есть сегодня.
Классическая книга C ++ Template Metaprogramming: понятия, инструменты и методы из Boost and Beyond поставляется с 20-страничным приложением для профилирования затрат времени компиляции. У этого есть компаньонный компакт-диск с кодом, который генерирует графики в этом приложении.
Другая бумага - http://aszt.inf.elte.hu/~gsd/s/cikkek/profiling/ profile.pdf , возможно, это вам полезно.
Еще один, но более трудоемкий способ - подсчитать количество экземпляров каждого класса из вашего компилятора.
Я знаю, что это старый вопрос, но есть более новый ответ, который я хотел бы дать.
Существует цельный набор проектов, предназначенных для этой конкретной проблемы. Первый компонент - это инструментарий для компилятора clang, который дает полную трассу всех экземпляров шаблонов, которые произошли во время компиляции, с указанием значений времени и, при необходимости, использования памяти. Этот инструмент называется Templight, как доступно здесь (в настоящее время он должен скомпилироваться с поврежденным деревом источника clang):
https://github.com/mikael-s-persson/templight
Второй компонент - это инструмент преобразования, который позволяет вам преобразовывать трассировки templight в другие форматы, такие как легко анализируемый текстовый формат (yaml, xml, text и т. д.) и в форматы, которые можно легко визуализировать, например, graphviz / graphML и, что более важно, вывод callgrind, который может быть загружен в KCacheGrind для визуализации и проверки мета-графика вызовов экземпляров шаблонов и их затрат времени компиляции, таких как этот снимок экрана шаблонный экземпляр кода куска кода, который создает boost::container::vector и сортирует его с std::sort:
[/g3]
Проверьте здесь:
https://github.com/mikael-s-persson/templight-tools
Наконец, есть и другой связанный проект, который создает интерактивную оболочку и отладчик, чтобы иметь возможность интерактивно alk вверх и вниз по шаблону экземпляра шаблона:
-
1
-
2Это самая удивительная вещь для метапрограммирования шаблонов ... Мне больше не нужно догадываться о том, что происходит ... Я могу на самом деле ПОСМОТРЕТЬ! – DarthRubik 15 February 2017 в 18:56
http://www.cs.uoregon.edu/research/tau/about.php может быть чем-то, что может представлять интерес для шаблонных объектов, это показывает распад времени, проведенного для каждого экземпляра. Другие данные включают, сколько раз каждая функция была вызвана, сколько профилированных функций вызывало каждую функцию и какое среднее время включительно для каждого вызова было
-
1Насколько я могу судить, он учитывает время, затрачиваемое в каждом экземпляре в runtime . Это не то, что было после OP. – quant 14 October 2014 в 07:36