Каковы последствия производительности этих функций C #?

Question

Я проектировал библиотеку для игр на основе компонентов с общим намерением написать ее на C ++ (как это моя сильная сторона) с Ogre3D в качестве бэк-энда.Теперь, когда я на самом деле готов написать некоторый код, я подумал, что будет гораздо быстрее протестировать мой фреймворк в фреймворке XNA4.0 (несколько быстрее получить результаты / написать редактор и т. Д.).Однако, хотя я не новичок в C ++ или C #, я я немного новичок, когда дело доходит до «XNA», так сказать, у меня было несколько запросов, прежде чем я началВыработка кода:

1. Я читал об использовании массивов, а не коллекций, чтобы избежать снижения производительности, а также прочитал, что это не совсем верно и что если вы перечислили, скажем, конкретный *В коллекции 1007 * (в отличие от IEnumerable<>) перечислитель является типом значения, который используется для каждой итерации и здесь нет никаких проблем GC.Рассматриваемая статья была еще в 2007 году. Верно ли это, или у вас, опытных разработчиков XNA, есть реальные черты об этом?В идеале я хотел бы пойти по выбранному маршруту, прежде чем я сделаю слишком много.

2. Если массивы действительно подходят, нет вопросов, я полагаю, когда дело доходит до изменения размерамассив, вы копируете старый с новым пробелом?Или это неправильно?Вы пытаетесь изменить размер массива?Разве GC не подойдет для старого, если это так, или это попадание несущественно?

3. Поскольку движок был разработан для C ++, конструкция позволяет использовать лямбдыи делегаты.В одном проекте используется библиотека fastdelegate, которая является самым быстрым способом использования делегатов в C ++.Более гибкий, но немного более медленный подход (хотя он едва заметен в мире C ++) - это использование C ++ 0x lambdas и std::function.В идеале я хотел бы сделать что-то подобное в XNA и разрешить использование делегатов.Вызывает ли использование делегатов какие-либо существенные проблемы в отношении производительности?

4. Если существуют соображения относительно производительности в отношении делегатов, есть ли разница между:

   public void myDelegate(int a, int b);
   private void myFunction(int a, int b)
   {
   }
   
   event myDelegate myEvent;
   
   myEvent += myFunction;
   

против:

    public void myDelegate(int a, int b);

    event myDelegate myEvent;

    myEvent += (int a, int b) => { /* ... */ };

Извините, если я немного колеблюсь, я предпочитаю быть ясным в своих вопросах.:)

Заранее спасибо!

Answer 1

По сути, единственная серьезная проблема с производительностью, о которой нужно знать в C #, которая отличается от той, которую вы должны знать в C ++, - это сборщик мусора. Просто не выделяйте память во время основного игрового цикла, и все будет в порядке. Вот пост в блоге, который подробно описан .

Теперь к вашим вопросам:

1) Если итератор коллекции фреймворка можно реализовать как тип значения (без создания мусора), то обычно (всегда?) Это так. Вы можете безопасно использовать foreach, например, List<>.

Вы можете проверить, выделяете ли вы в свой основной цикл, используя CLR Profiler .

2) Используйте List s вместо массивов. Они будут обрабатывать изменение размера для вас. Вам следует использовать свойство Capacity, чтобы заранее выделить достаточно места перед началом игры, чтобы избежать проблем с сборкой мусора. Используя массивы, вам просто нужно реализовать все эти функции самостоятельно - безобразно!

GC запускает распределение (не когда память становится свободной). На Xbox 360 он включается на каждый выделенный 1 МБ и работает очень медленно. В Windows это немного сложнее, но также не оказывает такого большого влияния на производительность.

3) C # делегаты чертовски быстры. И быстрее, чем большинство людей ожидают. Они примерно соответствуют вызовам методов на интерфейсах. Здесь и здесь - это вопросы, которые предоставляют больше подробностей о производительности делегата в C #.

Я не могу сказать, как они сравниваются с опциями C ++. Вы должны были бы измерить это.

4) Нет. Я уверен, что этот код будет выдавать идентичный IL. Вы можете разобрать его и проверить или профилировать.

Я мог бы добавить - не проверяя себя - я подозреваю, что event myDelegate будет медленнее, чем простая myDelegate, если вам не нужна вся магия event.