Мы занимаемся разработкой крупного финансового приложения в банке. Все началось с 150 тыс. Строк действительно плохого кода. К 1 месяцу назад это сократилось чуть более чем на половину, но размер исполняемого файла все еще был огромен. Я ожидал, что, поскольку мы просто делаем код более читабельным, но шаблонный код все еще генерирует большое количество объектного кода, мы просто стали более эффективными с нашими усилиями.
Приложение разбито на 5 общих объектов и один основной. Один из больших общих объектов был 40 МБ и вырос до 50, даже когда код сокращался.
Я не был полностью удивлен, что код начал расти, потому что в конце концов мы добавляем некоторую функциональность. Но я был удивлен, что он вырос на 20%. Конечно, никто не приблизился к написанию 20% кода, поэтому мне сложно представить, как он вырос. Мне сложно анализировать этот модуль, но в пятницу у меня появились новые точки данных, которые проливают некоторый свет.
Возможно, имеется 10 каналов для серверов SOAP. Код генерируется автоматически, плохо. У каждого сервиса был один класс синтаксического анализатора с точно таким же кодом, что-то вроде:
#include <boost/shared_ptr.hpp>
#include <xercesstuff...>
class ParserService1 {
public:
void parse() {
try {
Service1ContentHandler*p = new Service1ContentHandler( ... );
parser->setContentHandler(p);
parser->parser();
} catch (SAX ...) {
...
}
}
};
Эти классы совершенно не нужны, работает одна функция. Каждый класс ContentHandler был сгенерирован автоматически с теми же 7 или 8 переменными, которыми я смог поделиться с наследованием.
Так что я ожидал, что размер кода уменьшится, когда я удалил классы синтаксического анализатора и все из кода. Но только с 10 сервисами я не ожидал, что он упадет с 38 МБ до 36 МБ. Это невероятное количество символов.
Единственное, о чем я могу думать, - это то, что каждый анализатор включал в себя boost :: shared_ptr, некоторые вещи синтаксического анализатора Xerces, и что каким-то образом компилятор и компоновщик постоянно сохраняют все эти символы для каждого файла. Мне любопытно узнать в любом случае.
Итак, кто-нибудь может подсказать, как мне отследить, почему такая простая модификация должна иметь такой большой эффект? Я могу использовать nm на модуле, чтобы посмотреть на символы внутри, но это приведет к мучительному, огромному количеству полупонятных вещей.
Кроме того, когда коллега запустила свой код с моей новой библиотекой, пользовательское время изменилось с 1 до 55 секунд. Реальное время очень изменчиво, потому что мы ждем на медленных серверах SOAP (ИМХО, SOAP - невероятно плохая замена для CORBA ...), но процессорное время довольно стабильно. Я ожидал бы небольшого увеличения от уменьшения размера кода, но суть в том, что на сервере с огромной памятью я был действительно удивлен, что на скорость повлияло так много, учитывая, что я не изменил архитектуру Сама обработка XML.
Я собираюсь пойти еще дальше во вторник и, надеюсь, получу больше информации, но если у кого-то есть представление о том, как я могу добиться такого большого улучшения, я хотел бы знать.
Обновление:
Я проверил, что на самом деле наличие отладочных символов в задаче вообще не меняет времени выполнения. Я сделал это, создав заголовочный файл, который включал в себя множество вещей, в том числе два, которые имели здесь эффект: улучшил общие указатели и некоторые из XML-парсеров xerces. Кажется, что нет никакого снижения производительности во время выполнения (я проверил, потому что были различия во мнениях между двумя ответами). Тем не менее, я также проверил, что включение заголовочных файлов создает символы отладки для каждого экземпляра, даже если размер удаленного двоичного файла не изменился. Таким образом, если вы включаете данный файл, даже если вы его даже не используете, существует фиксированное количество символов, возражаемых против этого объекта, которые не складываются во время соединения, даже если они предположительно идентичны.
Мой код выглядит так:
#include "includetorture.h"
void f1()
{
f2(); // call the function in the next file
}
Размер с моими конкретными включаемыми файлами составлял около 100 КБ на исходный файл.Предположительно, если бы я включил больше, он был бы выше.Общий исполняемый файл с включениями был ~ 600 КБ, без 9 КБ.Я проверил, что рост линейен с количеством файлов, выполняющих включение, но раздетый код имеет одинаковый размер независимо от того, как и должно быть.
Я явно ошибался, думая, что это было причиной увеличения производительности,Я думаю, что я учел это сейчас.Несмотря на то, что я не удалил много кода, я упростил большую обработку больших XML-строк и значительно сократил путь к коду, и это, вероятно, является причиной.