Сразу говорю - условия весьма специфические, однако какая-то странная картина нарисовалась.
Тесты проводились на ASP Linux Server 4, машинка довольно дохлая, диск один. Сначала один сервер, затем переустановка, другой. Конфиги по дефолту. База наша рабочая, только справочники и конфигурация, без документов. Бэкап локальный, без service_mgr (на 1.0.3 нет, для чистоты сравнения) 1.0.3 - 77 с 2.0.1 - 71 с (+8%) Рестор локальный 1.0.3 - 298 с 2.0.1 - 321 с (-7%) Бэкап-рестор (через stdout, без промежуточного файла) 1.0.3 - 378 с 2.0.1 - 395 с (-5%) Налили 10 млн. записей в одну из таблиц, после этого бэкап-рестор (через stdout, без промежуточного файла) 1.0.3 - 757 с 2.0.1 - 775 с (-3%) В свежеотресторенной базе, update этих 10 млн. записей (одним стэйтментом) 1.0.3 - 326 с 2.0.1 - 369 с (-12%) Теперь тестирую сборку мусора (прибил эти 10 млн. записей). gfix -sweep 1.0.3 - 213 с 2.0.1 - 235 с (-10%) Бэкап со сборкой мусора, локальный, без service_mgr 1.0.3 - 374 с 2.0.1 - 398 с (-6%) Сборка мусора с помощью select count(*) from table1 1.0.3 - 182 с 2.0.1 - 199 с (-9%) Кроме бэкапа, 2.0.1 слила по всем пунктам "теста". Неужели вся оптимизация только на многопользовательской работе видна будет? Сборка мусора меня несколько озадачила. В каких условиях она будет (как обещали "гораздо") быстрее чем единица? -- Сергей Смирнов.
