List< Image > l1 = new List< Image >();
for( int i = 0; i < 2; ++i )
l1.Add( Properties.Resources.help );
Image img = Properties.Resources.help;
List< Image > l2 = new List< Image >();
for( int i = 0; i < 2; ++i )
l2.Add( img );
Text = l1[0].Equals(l1[1]) + " " + l2[0].Equals(l2[1]);
Оптимизация кода на C#
Написал две статьи по оптимизации кода на C#:
http://itw66.ru/blog/c_sharp/542.html - Работа с ресурсами сборки
http://itw66.ru/blog/c_sharp/543.html - Создание класса ObjectPool для эффективной работы с большим количеством объектов интерфейса
А вы какие способы оптимизации кода можете предложить?
http://itw66.ru/blog/c_sharp/542.html - Работа с ресурсами сборки
http://itw66.ru/blog/c_sharp/543.html - Создание класса ObjectPool для эффективной работы с большим количеством объектов интерфейса
А вы какие способы оптимизации кода можете предложить?
Глянул первую ссылку. Рано вам ещё советы по оптимизации давать. Подучитесь.
Посмотрите, что выведется, и озадачьтесь...
Код:
Посмотрите, что выведется, и озадачьтесь...
Глянул вторую ссылку.
Цитата:
Поскольку в C# используется управляемая сборка мусора
А что, бывает неуправляемая сборка мусора?
Цитата:
нет возможностей контролировать создание, размещение и удаление объектов
Про unsafe в C# никогда не слышали?
Цитата:
При этом идет постоянное создание и уничтожение объектов. Это не эффективно ни с точки зрения производительности, т.к. выделение и освобождение памяти — это долгая операция (ни считая сборки мусора, которая так же занимает время)
Выделение памяти в .NET - практически бесплатная операция.
Читайте про работу GC и управление памятью, прежде чем писать такое!
Цитата:
ни с точки зрения памяти, т.к. она постоянно фрагментируется.
:facepalm:
Дальше читать не стал.
По поводу этого:
Цитата:
Text = l1[0].Equals(l1[1]) + " " + l2[0].Equals(l2[1]);
Так и я это же написал, что в первом случае создаются новые объекты, но этого не нужно. Если я хочу на 10 кнопок назначить одну и ту же картинку, то зачем ее 10 раз в памяти хранить то. Поэтому я и написал, что нужно ресурсы грузить один раз и работать с ними, вместо того, чтобы делать это каждый раз.
Цитата:
Выделение памяти в .NET - практически бесплатная операция.
То то я смотрю, что каждая новая версия какой-нибудь программы все больше и больше тормозит. Как раз потому, что программисты думают, что выделение памяти бесплатно. Если бы ты пописал программы для устройств с ограниченной памятью, то тогда понял бы, что оперативная память - это одно из самых узких мест современной вычислительной техники.
Заполни какое нибудь TreeView десятью тысячами записей и когда у тебя будет столл в две секунды на "бесплатном выделение памяти", скажи, что я не прав.
Цитата: FiloXSee
Так и я это же написал, что в первом случае создаются новые объекты, но этого не нужно. Если я хочу на 10 кнопок назначить одну и ту же картинку, то зачем ее 10 раз в памяти хранить то. Поэтому я и написал, что нужно ресурсы грузить один раз и работать с ними, вместо того, чтобы делать это каждый раз.
Взялись писать блог - будьте добры давать точные формулировки.
А если в дальнейшем надо менять полученные из ресурсов объекты? То-то начинающий программист, последовав вашему совету, будет удивлён, когда меняться станет сразу всё.
Отредактируйте первый пост, объясните более подробно (понятно начинающим!), что в одном случае происходит копирование объекта, а в другом - копирование ссылки на один и тот же объект.
Цитата: FiloXSee
То то я смотрю, что каждая новая версия какой-нибудь программы все больше и больше тормозит. Как раз потому, что программисты думают, что выделение памяти бесплатно.
Да, выделение памяти в дотнете - это лишь перемещение одного указателя. Выделение памяти в нативной куче - гораздо более тяжеловесная операция.
Если объект был создан, и почти тут же удалён, то сборщик мусора может и не действовать при этом, поэтому не нужно его приплетать к каждому случаю.
Цитата: FiloXSee
Если бы ты пописал программы для устройств с ограниченной памятью
15 килобайт оперативки - достаточно мало? Писал под такое устройство очень много.
А начинал я программировать на устройстве с памятью 512 байт...
Цитата: FiloXSee
то тогда понял бы, что оперативная память - это одно из самых узких мест современной вычислительной техники.
Объём памяти или пропускная способность шины? ;)
Цитата: FiloXSee
Заполни какое нибудь TreeView десятью тысячами записей и когда у тебя будет столл в две секунды на "бесплатном выделение памяти", скажи, что я не прав.
Таки шо, это проблема C#? Или же это проблема создания большого количества объектов? То же самое будет в любом другом языке, в любой платформе. Да, пул может помочь. Вот только при чём тут наезд на сборщик мусора и управляемый код - хз.
И напоследок:
[QUOTE=MSDN]lock (this) может привести к проблеме, если к экземпляру допускается открытый доступ.[/QUOTE]
P.S. перл про фрагментирование памяти в дотнете уберите - засмеют...
Учел некоторые пожелания.
Цитата: koodeer
P.S. перл про фрагментирование памяти в дотнете уберите - засмеют...
На самом деле фрагментация памяти в CLR вполне реальное явление, если, конечно, говорить о LOH - куче больших объектов - объекты в ней никуда не перемещаются и при длительной работе с большими массивами можно вполне получить OutOfMemoryExcption. Это еще один повод для перехода на x64 - там фрагментация памяти влияет меньше (да и JIT код получше выдает).
Цитата: FiloXSee
Заполни какое нибудь TreeView десятью тысячами записей и когда у тебя будет столл в две секунды на "бесплатном выделение памяти", скажи, что я не прав.
А зачем нужно заниматься этим идиотизмом? Для отображения большого количества объектов совсем не обязательно создавать аналогичное количество элементов интерфейса (которые, кстати, следует считать ресурсом). Поищите в сети про виртуальные списки, гриды и т.п. - идея заключается в том, чтобы создавать элементов интерфейса столько, сколько в данный момент времени видно/нужно пользователю.
Цитата: koodeer
Про unsafe в C# никогда не слышали?
На создание объектов и правда влиять не можем. Зато можем предсказать начало stop-world GC.
Цитата: koodeer
Выделение памяти в .NET - практически бесплатная операция.
Читайте про работу GC и управление памятью, прежде чем писать такое!
Читайте про работу GC и управление памятью, прежде чем писать такое!
Если уж говорить о хардкорных оптимизациях, то правда - создание объектов перестает быть сравнительно "бесплатной" операцией, "бесплатной" она остается лишь для структур. В предельных случаях на производительность могут влиять слишком длинные цепочки вида x.PropA.PropB.PropC - излишняя косвенность оказывает существенное влияние на производительность: процессор тем и занимается что вычисляет адреса.
Цитата: koodeer
Дальше читать не стал.
+1 автору прежде чем публиковать опусы необходимо ознакомиться с существующем материалом, коего в интернетах достаточно (и, кстати, орфорграфию подтянуть немешало бы). Означенные оптимизации очевидны и общеизвестны, но вот код, как говорится, "без слез не взглянешь".
Цитата:
А зачем нужно заниматься этим идиотизмом? Для отображения большого количества объектов совсем не обязательно создавать аналогичное количество элементов интерфейса (которые, кстати, следует считать ресурсом). Поищите в сети про виртуальные списки, гриды и т.п. - идея заключается в том, чтобы создавать элементов интерфейса столько, сколько в данный момент времени видно/нужно пользователю.
А можно ссылочку на подобное применение в C#. Я такое делал только в списках на iPhone.
После непродолжительного отсутствия, я снова в теме.
Цитата: FiloXSee
Учел некоторые пожелания.
Посмотрел. Так мне нравится несколько больше.
Ма-а-аленькое замечание: фон для кода в виде тетрадного листочка в клеточку как-то слишком наводит на мысль о школе... школотизм, ага :). Но это моё субъективное мнение.
Цитата: hardcase
Для отображения большого количества объектов совсем не обязательно создавать аналогичное количество элементов интерфейса (которые, кстати, следует считать ресурсом). Поищите в сети про виртуальные списки, гриды и т.п. - идея заключается в том, чтобы создавать элементов интерфейса столько, сколько в данный момент времени видно/нужно пользователю.
Цитата: FiloXSee
А можно ссылочку на подобное применение в C#.
Я тоже хотел упомянуть про виртуализацию.
Вспомнилась вот эта тема: http://www.gotdotnet.ru/forums/3/137820/648992/ Посмотрите примеры кода Algol36 - миллион элементов - пустяк!
Что ещё могу вспомнить с ходу. Например, это: MSDN DataGridView.VirtualMode
Цитата: hardcase
На самом деле фрагментация памяти в CLR вполне реальное явление, если, конечно, говорить о LOH - куче больших объектов - объекты в ней никуда не перемещаются и при длительной работе с большими массивами можно вполне получить OutOfMemoryExcption.
Эх, я когда штудировал работу с памятью в дотнете, так и не нашёл описания работы LOH. Везде пишут про кучу маленьких объектов, про то как GC её уплотняет и т. п. Также не нашёл толковых описаний, что будет, если объект зафиксировать в памяти (fixed): может ли это создать фрагментацию, как GC будет обходить этот "пришпиленный" кусок памяти?
Впрочем, я не шибко искал (хотя спрашивал - никто вроде не ответил).