incredibuild
Распределённые вычисления рулят. Сейчас собираю проект, утилизируется 20 ядер, 55 ГГц в сумме, билд идёт уже 10 минут. А теперь представим, что ядер всего два
Все помнят, надеюсь, мою замечательную машину на работе. Так вот, всю неделю она работала как древний третий пень с убитым в хлам винтом. Начали копаться, выяснили, что во всём повинен именно винт. А что же это за винт? А это Жесткий диск 640ГБ Western Digital «Caviar Green WD6400AARS» 64МБ (SATA II). Человек, который его купил, сказал буквально следующее: «А что, новая технология (физический кластер 4 кб), первая партия, кеш на 64 метра покроет минусы от потерь на скорости вращения в 5400, ну и он будет жрать меньше электричества».
Что же получилось на самом деле:
Граждане, не покупайте экспериментальные комплектующие.
Метки:дневник, отчёт, рабочееРаспределённые вычисления рулят. Сейчас собираю проект, утилизируется 20 ядер, 55 ГГц в сумме, билд идёт уже 10 минут. А теперь представим, что ядер всего два
Будете смеяться, но после того, как я оптимизировал создание карты с 10 секунд до 23 миллисекунд, мы упёрлись в производительность стандартных коллекций.
Раньше, когда небо было голубое и трава зелёная, монстров у нас было чётко заданное количество. Поэтому был массив. Сейчас, количество мобов меняется, поэтому, недолго думая, был всунут List<T>. Всё бы ничего, но сервер тут же стал жрать в 4 раза больше проца. Замеры показали, что почти вся нагрузка – пересчёт монстров, из которого половину времени мы сидим в геттера List<T>.Item.
Думаем, что делать
Грабли, как мне кажется, есть везде. В своё время, ни одна библиотека не прошла мимо меня в проект, кроме, пожалуй, Infragistics, без доработки. Поговорим о граблях в System.AddIn.
Для начала порекомендую прочитать статью в блоге Джейсона Хи (Jason He), которая называется «Coding patterns to avoid in addin pipeline development». Да и вообще, его блог почитать надо, он поподробнее Walkthrough в MSDN.
Итак, первая грабля, на которую я наступил: дефолтные домены работают без ShadowCopy, как следствие, заменить сборки на горячем сервере мы не можем. Ок, нам особо и не надо, сделаем домен сами:
[cc lang="csharp"]
AddInStore.Update(pipelineRootFolderPath);
Collection tokens = AddInStore.FindAddIns(typeof(IView), pipelineRootFolderPath);
AddInToken calcToken = tokens[0];
AppDomain domain = AppDomain.CreateDomain(string.Format(«Test {0}», DateTime.Now), null, new AppDomainSetup { ShadowCopyFiles = «true» });
return calcToken.Activate(domain);
[/cc]
Затем мы работаем, всё ок. Для выгрузки аддона используем такой код: [cci lang="csharp"]AddInController.GetAddInController(calc).Shutdown()[/cci]. По идее всё хорошо, но есть одно но. Из-за того, что мы домен создали вручную, то автоматически инфраструктура System.AddIn его не выгрузит. Да, это может быть логично, но об этом нигде не написано.
Код ниже логичен, но будет падать, несмотря на то, что ссылка на домен у контроллера есть, и она живая. Просто разработчики посчитали, что раз AddIn отключен, то домен нам уже не нужен. Вообще, реализация AddInController’a с [cci lang="csharp"]lock(this)[/cci] и прочим меня ни разу не порадовала.
[cc lang="csharp"]
AddInController c = AddInController.GetAddInController(calc);
c.Shutdown();
AppDomain.Unload(c.AppDomain);
[/cc]
Правильный код вот такой:
[cc lang="csharp"]
AddInController c = AddInController.GetAddInController(calc);
AppDomain d = c.AppDomain;
c.Shutdown();
AppDomain.Unload(d);
[/cc]