Linq и ламбда изрази при използване на IL2CPP

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

sholeto 93 Точки

Linq и ламбда изрази при използване на IL2CPP

Едно от нещата, които запомних от лекцията за производителност беше, че не е препоръчително да се използват linq и ламбда изрази. Kакто, че е по-добре да се използват for loops вместо foreach. Въпросът ми е ако за крайния билд използваме IL2CPP, то има ли значение дали в скриптовете сме използвали тези неща, като в крайна сметка всичко ще се обърне към C++?

Малко пояснение за тези, които не знаят какво е IL2CPP (Intermediate Language To C Plus Plus) - това е технология, която Unity разработват от около две години. Взима Intermediate Language кода, който е резултат от компилацията на вашите C# скриптове и го обръща към C++ код, който съответно да се използва от компилаторите за съответната таргет платрофма, за която билдвате играта.

Не познавам как работи конкретно този процес, но си представям, че кода би се обърнал до един и същи C++ резултат преди да бъде компилиран, без значение дали съм използвал само for цикли или не. Вярно, че при самите тестове преди билда се използва Mono и ако има забавяне ще се усети докато тестваме играта преди да сме направили билда, но дали ще е чак толквоа значително? Интересно ми е вие какво мислите и дали има някой, който да е запознат по-добре с това?

Тагове:

18/04/2016 10:53:38 Unity 3D

IvayloSlavov 5 Точки

Интересен въпрос, и аз искам да знам отговора :) .

В допълнение към разсъжденията, бих добавил че корутините в Unity използват yield и IEnumerator. Имплементацията на LINQ за стандартни колекции в .NET, ако не се лъжа, е реализирана също чрез yield. В този смисъл не виждам LINQ да представлява нещо непознато и кой-знае колко по-трудно смилаемо за IL2CPP от колкото са корутините.

В същото време, самия .NET компилатор в повечето ситуации може да оптимизира for loops по-добре от колкото foreach (разбирайте .GetEnumerator() ). Употребата на LINQ би предотвратила възможността за такива оптимизации - може би това е причината, но до колкото знам, preformance benefit-а от тези оптимизации е минимален.

19/04/2016 20:49:09

kasskata 492 Точки

Здравейте колеги, ще се опитам да отговоря на въпроса ви.
Performance проблемите с LINQ библиотеката са:
1. при компилация на C++ code няма проблеми, всичко идва от платформата на която отивате. Objective C има проблем с интеграцията на този код, дефактно не се знае коя проекция ще се счупи. Най- голям успех имат Sort(), ThenBy(), Where().

2. Всяка заявка по Builder pattern e тежка. Това е ново заделяне на памет и доста дебело завъртане на колекция само за да ви даде FirstOrDefault, което се прави даже с for цикъл лесно. След като имате вече прожекцията на първото, ако имате следваща клауза тя заделя нова памет и нов foreach се започва. Тежък е по природа и не е писан за локална data.

3. Никой в практиката не предпочита LINQ, защото е безумно бавно и скъпо, в Back-end системите например работи до максимум 10 000-20 000 записа в таблица релативна с 1-2 таблички по няколко записа. И пак ще се задъха. Най-добрия избор винаги си остава querry stringa като скоростно решение, защото LINQ прави едни буламачи querry, което може да иска нещо малко, а всъщност да напише 1 mb string.

4. За Unity специално има 1 plugin-че, което прави същото функционално програмиране, но доста по-леко ТУК

Интересен факт:

Във версията .NET, която се ползва в момента (3.5), string.Format() e до 3 пъти по-бавен от конкатинацията на големи стрингове. Не очаквайте нормално поведение от C# скрипт към Mono. С голямо нетърпение чакам да излезне версията в която заменят MONO с Roslyn.

09/09/2016 11:20:26 09/09/2016 11:25:35

dead4y 62 Точки

Хората по форумите се оплакват че не върни на IOS.

Освен ако не мислиш да го ползваш в (Fixed)Update функцията(метода) или мислиш да правиш голямо MMORPG, не мисля че е проблем.

09/09/2016 14:02:31