Приложението .Net 4.0 е по-бавно на 64 бита от 32 бита (Профилиране и възможни решения) (приложението използва NetAdvantage)

Имаме .NET приложение, написано на VB .NET 4.0 / VS2010, компилирано с всички проекти, настроени на настройката AnyCPU както за конфигурация Debug, така и Release. Забелязахме, че когато това приложение се изпълнява в 64-битова среда (тествано на Windows Server 2003 R2 и 2008 R2), приложението след това отнема поне двойно повече време (в абсолютно изражение около 25 секунди) за разлика от около 6-12 секунди в 32-битова среда (Win XP и 7), за да стартирате.

Трябва да добавя, че 64 битовите системи са мощни сървъри, определено по-мощни от другите тествани 32 битови системи. Всички други приложения бяха по-бързи на 64 бита, но не и нашето лошо приложение ;) (И тествахме приложенията по различно време, при различно натоварване и резултатите винаги са почти еднакви.)

Както беше казано по-горе, приложението е създадено с помощта на AnyCPU и работи като 64-битова сборка под 64-битова операционна система (проверено чрез TaskManager). Самото приложение е приложение WinForms, което използва NetAdvantage Forms v10.3 и редовно прави заявки и пише на MS SQL Server 2008.

Всички различни целеви машини са в една и съща мрежа, така че пътят до базата данни (същата база данни беше използвана за тестовете за производителност) например е един и същ, не мисля, че проблемът е около базата данни или самата мрежа.

Едно нещо, което забелязах, което ми се стори странно, беше, че когато изградих различни „стъпки за профилиране“, използвайки хронометър по време на стартирането на нашия MainForm, методът InitializeComponent отне два пъти повече време на 64 бита, около 4 секунди за разлика от 1,5 на 32 бита.

Това е едно и също приложение, което внедряваме и в двете системи, без различна конфигурация.

Така че имам два въпроса:

Някаква идея каква може да е причината за това?

И: Кой е най-добрият начин за определяне на "проблемните" части от код? В момента използвам хронометри и се опитвам да го стесня. Но ми се струва, че всичко е по-бавно на 64-битовите машини, що се отнася до нашето приложение, така че не съм много сигурен, че мога да го разделя на конкретни твърдения.

Благодаря на всички за помощта, много оценявам...


.net performance 64-bit 32bit-64bit infragistics
person ManOnAMission    schedule 19.10.2012    source източник
comment
Ако вашата среда за разработка е 64-битова, опитайте да стартирате Profiler с помощта на Performance Wizard във Visual Studio.   -  person Moon    schedule 19.10.2012
comment
Съжалявам, че не прочетох целия въпрос, но проверете дали това ви помага: stackoverflow.com/q/2947118/389966   -  person Adi Lester    schedule 19.10.2012
comment
Забелязах точно същото и публикувах въпрос тук: stackoverflow.com/questions/7161080/   -  person Boris B.    schedule 19.10.2012
comment
@Луна. Не, това е 32-битова среда за разработка. Но може да получа достъп до 64-битов dev env. Благодаря за бакшиша. Редактиране: О, но имаме само VS Professional - това няма да работи, нали?   -  person ManOnAMission    schedule 19.10.2012
comment
Не предполагайте нищо. Измерете.   -  person Hans Passant    schedule 19.10.2012
comment
Red Gate и JetBrains предлагат изпробвания на страхотни приложения за профилиране. Безполезна игра е да се опитвате да познаете къде е затънало някое произволно приложение.   -  person roken    schedule 20.10.2012

Отговори (3)


arrow_upward
4
arrow_downward

Оказа се, че веднага щом превключихме от компилиране от AnyCPU към конкретно x86, т.е. работим и като x86 на x64 битова платформа, се върнахме към нашата „добра скорост“.

person ManOnAMission    schedule 20.11.2012
comment
Добре е, че се върнахте към бързата скорост, като компилирахте директно към 32-битов, който работи като 32-битов процес, но намерихте ли някога отговор защо стартирането на вашето приложение отне повече време? Колко RAM имаха вашите x64 сървъри? - person tap; 14.04.2013
comment
Едно нещо, което ми хрумна е, че използваме интензивно NetAdvantages WinForms. Склонен съм да мисля, че те използват код, който работи по-бързо в 32-битови среди, но не съм потвърдил това. Всеки повече опит в това отношение е добре дошъл. И относно въпроса за RAM: Имаме много RAM на всички машини, всички с еднаква скорост и много резервна RAM по време на изпълнение, така че трябва да е някъде другаде. - person ManOnAMission; 11.05.2013
comment
Запомнете това, platform target не променя компилирания IL-код, това е само ограничение за JIT-compiler. Ограничението е най-вече полезно при използване на собствени API (компилирани за конкретна целева платформа) - person Jeroen van Langen; 21.12.2013

arrow_upward
4
arrow_downward

Имах същия проблем - и да, JIT е виновен. Чрез разумно използване на msgbox го стесних до метод, който ще отнеме 10 секунди, за да започне (чрез извикване на кутията за съобщения точно преди извикването на големия метод и след това като първия ред на голямата функция.) И , да, видях това само при компилиране като AnyCPU, но не и когато изрично x86; а не когато работи в debug.

В моя случай това беше 5000 реда Windows Forms InitializeComponent.

За да докажете това, изпълнете (повишен) "c:\windows\<.net framework dir>\ngen.exe install <myassembly.exe>", който ще компилира естествено изображение. Ако това го поправи, тогава да, JIT беше виновен.

Дългосрочни корекции или:

  • използвайте ngen всеки път, когато разгръщате програмата, за да възстановите собственото изображение (или ngen update за повторно изграждане, но очевидно работи само след инсталиране веднъж); (Недостатъкът е управлението на изображението(ята) на ngen и времето, необходимо за ngen. Това е маршрутът, който поех, защото има цялостно повишаване на производителността за по-големи приложения.)

  • или можете да добавите атрибута <System.Runtime.CompilerServices.MethodImpl(MethodImplOptions.NoOptimization)> към метода. (Деактивира JIT на метода, така че е по-бавно за изпълнение но не плащате първоначалните режийни разходи за JITing, което е скъпата част за нас)

(Подозирам, че правенето и на двете е безплодно, тъй като това би означавало да се откажем от родния образ на големия метод без печалба.)

person user2006616    schedule 09.12.2014

arrow_upward
2
arrow_downward

Наскоро имах същия проблем с производителността на приложение. И да, компилирането като x86 реши проблема; след това работи бързо и на двете платформи. Но истинската причина за бавното време за реакция при стартиране се дължи на проблеми с миграцията от 32 към 64 бита. Мисля, че когато приложението се стартира и преминава през JIT процеса, за да превърне кода в IL, компилаторът определя, че съществуват проблеми в кода (като де-тип безопасен код), които той трябва да разреши, преди да може да работи в 64 бита режим. Попаднах на тази статия и сега се опитвам да прегледам приложението, за да определя кои части причиняват проблемите. Вижте тази статия: http://msdn.microsoft.com/en-us/library/ms973190.aspx. Бих могъл да го оставя сам, тъй като работи, но в идеалния случай би работил по-добре в 64-битов режим, ако проблемите бяха разрешени.

person DavidC    schedule 28.02.2014
comment
Интересно! Моля, публикувайте повече, когато го разгледате по-подробно. - person ManOnAMission; 01.03.2014