C# без платформы.NET
В случае Linq к объектам, возвращаясь List<T> от функции не так хорошо как возврат IList<T>, как указывает ПОЧТЕННАЯ СТРЕЛЬБА ПО ТАРЕЛОЧКАМ. Но часто можно все еще добиться большего успеха, чем это. Если вещь, которую Вы возвращаете, должна быть неизменной, IList является плохим выбором, потому что это приглашает вызывающую сторону добавлять или удалять вещи.
, Например, иногда у Вас есть метод или свойство, которое возвращает результат запроса Linq или использует yield return для ленивой генерации списка, и затем Вы понимаете, что было бы лучше сделать это в первый раз, когда Вас звонят, кэшируете результат в List<T> и возвращаете кэшированную версию после этого. Именно тогда возврат IList может быть плохой идеей, потому что вызывающая сторона может изменить список в их собственных целях, которые тогда повредят Ваш кэш, делая их изменения видимыми во все другие вызывающие стороны.
Лучше для возврата IEnumerable<T>, таким образом, все они имеют, вперед повторение. И если вызывающая сторона хочет быстрый произвольный доступ, т.е. им жаль, что они не могли бы использовать [] для доступа индексом, они могут использовать ElementAt, который определяет Linq так, чтобы это бесшумно осуществило сниффинг для IList и использование, что при наличии, и если не это делает немой линейный поиск.
Одна вещь я использовал ToList для, когда у меня есть сложная система выражений Linq, смешанных с пользовательскими операторами, которые используют yield return, чтобы отфильтровать или преобразовать списки. Продвижение через в отладчик может стать могущественным сбивающий с толку, когда это переходит вокруг выполнения отложенных вычислений, таким образом, я иногда временно добавляю ToList () к нескольким местам так, чтобы я мог более легко следовать за путем выполнения. (Хотя, если вещи Вы выполняетесь, имеют побочные эффекты, это может изменить значение программы.)
6 ответов
C # и .Net - это собственный код . Я думаю, вы неправильно поняли JITter. Это не виртуальная машина. Программа на C # компилируется в полностью машинный код до того, как будет выполнена какая-либо из ее частей.
Теперь проблема «нужны другие компоненты». Но дайте ему время. В наши дни вам будет трудно найти установку Windows без по крайней мере .Net 2.0, и даже пара основных дистрибутивов Linux включает моно из коробки.
В качестве примечания: в Mono предусмотрена полная опережающая компиляция, что исключает время выполнения. (Думаю, именно так они и ускользают от работы на iPhone, который запрещает любую JIT.)
Было показано, что скомпилированные программы .NET работают так же быстро, как и C. Если вы хотите, чтобы они были сверхлегкими, напишите их на ассемблере для вашего собственного процессора.
Не думайте, что JIT замедляет работу. JIT может оптимизироваться для конкретного компьютера, на котором выполняется приложение, а не для обычного компьютера, такого как 386 или Pentium. Он может даже принимать лучшие решения о соотношении скорости / памяти при генерации кода, поскольку точно знает, что доступно. И если JIT по-прежнему замедляет работу, вы можете NGEN их, чтобы JITting выполнялся заранее.
В качестве доказательства этого предположим, что Quake был перенесен на CLR пару раз, а в Мои личные тесты, частота кадров в секунду была быстрее , когда Quake запускается на CLR примерно в половине случаев, когда я демонстрировал его.
есть, C .C можно использовать для написания любых приложений !!!
Обратите внимание на Erlang:
Вам нужна песочница / DSL: вы можете написать «генераторы синтаксического анализатора» для очистки доступа к критическим / уязвимым системным вызовам. Стандартный компилятор можно «легко» улучшить с помощью этой функциональности.
Вам необходимо детальное планирование: у вас есть некоторый контроль над этим также при условии, что вы запускаете каждого «пользователя» в отдельных эмуляторах. Может, у тебя получится лучше, но мне придется копать больше. Помните, что планирование - O (1): -)
Вам необходимо разделение ресурсов между вашими «игроками» (думаю, если я правильно понял): Erlang не имеет разделяемого состояния, так что это помогает с самого начала. Вы можете легко создать несколько супервизоров, которые наблюдают за потреблением ресурсов игроками и т. Д. См. Также ссылку в пункте выше (множество регуляторов для управления эмулятором).
Вам нужна горячая замена кода: См. документацию MSDN NGEN . Microsoft уже обдумывает, что вы здесь получаете.
Microsoft также делает инструмент ILMERGE.EXE для объединения нескольких файлов сборки в один. Это тоже может граничить с оптимизацией и скоростью.