Victor_VG
Tracker Mod | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору mex3 В отчёте есть цифры, это раз, но и новое есть, это факт - из-под запущенной с Hiren's BOOT CD Mini-XP тот же самый тестовый 1751 "добрался" в расходе памяти по данным её Process Explorer'а со стартовых 1,5 Мб до отметки 4 Мб на которой и остановился. А вот когда, тот же самый бинарник был скопирован на другую машину, то там картина повторилась полностью. И в данном случае, я думаю мы должны смотреть цифры как отсчёты после того, как поймём что происходит как явление в целом. А мы наблюдаем чёткую взаимосвязь событий "отдана команда - новый запрос к системе на выделение памяти для её исполнения". Тут даже код системных библиотек можно не проверять - графики изменения расхода ОЗУ с учётом отработки команд показывают что происходит. А вот цифры, а не "красивые картинки" нам потребуются для того, чтобы регулировки где надо подкрутить. На начальном этапе анализа нужны не отсчёты, а понимание. Вот и давайте вместе смотреть, то что у нас появилось после проверки на другой машине. Оговорюсь сразу - я специально выбирал для проверки далеко расположенную машину, настроенную другими специалистами и с другим набором ПО. Я это сделал для того, что бы исключить вероятность влияния настроек первого стенда на результат. И вот итоги измерений на двух других, чужих машинах машинах под XP SP3: Far 2.0.1751, просто переходим по каталогам. Машина: m/b i815, iPentium !!! 866 MHz Coppermine, 512 Mb RAM, GeForce 440 MX, XP Home SP3 Rus. Каждый переход в другой каталог приводит к скачку объёма используемой памяти. Поведение для сборки с farmanager.com аналогично. Собрал специально Far 2.0.1752 со стандартным набором плагинов. Проверял на другой системе: m/b i829, P4 1700 MHz, 1 Gb RDRAM, ATI X800, XP Pro SP3 Rus. Тут вообще кроме переходов по каталогам в пределах плюс минус три соседних по уровню вложенности ничего не делалось. Никаких команд не отдавалось. В каталогах в среднем по 5 - 6 файлов, но не более 10. Поведение собранного в MS VisualStudio 2010 варианта аналогична, разница в значения памяти - цифры показаний цифры больше на 100 - 105 Кб. В обоих случаях антивирусы отключались чтобы под руку не лезли, машины автономны, сети нет, операционная система каждый раз ставилась заново с резервной копии предоставленной изготовителем машины. Обе тестовые машины стоят в госструктурах и обслуживаются их людьми. Поэтому утверждение о том, что явление не установлено, я считаю результатом ошибки измерений. Даже совершенно бестолковый Microsoft TaskManager четко отслеживает факты скачка объёма памяти процесса, и кроме того, их можно отследить и в записях журналов производительности используя их как инструмент контроля правильности измерений. Для контроля во всех трёх сериях каждый опыт повторялся не менее 10 раз для исключения вероятности случайной ошибки и проводился независимыми испытателями. Поэтому, данное явление можно считать доказанным, а вот сроки и способы его устранения - это уже чисто рабочие моменты. Другое дело что его надо устранить, и это очевидно. И уже совсем для демонстрации "явления которого нет", прошу скрины-отчёты и бинарники с которых их получили: Это так ведёт себя сборка в MS VisualSudio 2008 SR1 Pro А это поведение GCC сборки. В обоих случая сборка осуществляет из не модифицируемых никоим образом исходников с использованием тех мэйков и проектов что написаны Far Groups для уверенности в невнесении в код посторонних настроек/патчей. Для проверки можно загрузить бинарники тут лежат. Пароля у архива нет, и пролежит столько, сколько потребуется для работы.
---------- Жив курилка! (Р. Ролан, "Кола Брюньон") Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti |
| Всего записей: 33210 | Зарегистр. 31-07-2002 | Отправлено: 15:05 10-12-2010 | Исправлено: Victor_VG, 19:25 10-12-2010 |
|