Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

Оптимизация кода на C#

65K
24 сентября 2011 года
FiloXSee
18 / / 01.07.2011
Написал две статьи по оптимизации кода на C#:
http://itw66.ru/blog/c_sharp/542.html - Работа с ресурсами сборки
http://itw66.ru/blog/c_sharp/543.html - Создание класса ObjectPool для эффективной работы с большим количеством объектов интерфейса

А вы какие способы оптимизации кода можете предложить?
297
24 сентября 2011 года
koodeer
1.2K / / 02.05.2009
Глянул первую ссылку. Рано вам ещё советы по оптимизации давать. Подучитесь.
 
Код:
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]);

Посмотрите, что выведется, и озадачьтесь...
297
24 сентября 2011 года
koodeer
1.2K / / 02.05.2009
Глянул вторую ссылку.


Цитата:
Поскольку в C# используется управляемая сборка мусора


А что, бывает неуправляемая сборка мусора?


Цитата:
нет возможностей контролировать создание, размещение и удаление объектов


Про unsafe в C# никогда не слышали?


Цитата:
При этом идет постоянное создание и уничтожение объектов. Это не эффективно ни с точки зрения производительности, т.к. выделение и освобождение памяти — это долгая операция (ни считая сборки мусора, которая так же занимает время)


Выделение памяти в .NET - практически бесплатная операция.
Читайте про работу GC и управление памятью, прежде чем писать такое!


Цитата:
ни с точки зрения памяти, т.к. она постоянно фрагментируется.


:facepalm:
Дальше читать не стал.

65K
24 сентября 2011 года
FiloXSee
18 / / 01.07.2011
По поводу этого:
Цитата:
Text = l1[0].Equals(l1[1]) + " " + l2[0].Equals(l2[1]);



Так и я это же написал, что в первом случае создаются новые объекты, но этого не нужно. Если я хочу на 10 кнопок назначить одну и ту же картинку, то зачем ее 10 раз в памяти хранить то. Поэтому я и написал, что нужно ресурсы грузить один раз и работать с ними, вместо того, чтобы делать это каждый раз.

Цитата:
Выделение памяти в .NET - практически бесплатная операция.


То то я смотрю, что каждая новая версия какой-нибудь программы все больше и больше тормозит. Как раз потому, что программисты думают, что выделение памяти бесплатно. Если бы ты пописал программы для устройств с ограниченной памятью, то тогда понял бы, что оперативная память - это одно из самых узких мест современной вычислительной техники.

Заполни какое нибудь TreeView десятью тысячами записей и когда у тебя будет столл в две секунды на "бесплатном выделение памяти", скажи, что я не прав.

297
24 сентября 2011 года
koodeer
1.2K / / 02.05.2009
Цитата: FiloXSee
Так и я это же написал, что в первом случае создаются новые объекты, но этого не нужно. Если я хочу на 10 кнопок назначить одну и ту же картинку, то зачем ее 10 раз в памяти хранить то. Поэтому я и написал, что нужно ресурсы грузить один раз и работать с ними, вместо того, чтобы делать это каждый раз.


Взялись писать блог - будьте добры давать точные формулировки.
А если в дальнейшем надо менять полученные из ресурсов объекты? То-то начинающий программист, последовав вашему совету, будет удивлён, когда меняться станет сразу всё.
Отредактируйте первый пост, объясните более подробно (понятно начинающим!), что в одном случае происходит копирование объекта, а в другом - копирование ссылки на один и тот же объект.


Цитата: FiloXSee
То то я смотрю, что каждая новая версия какой-нибудь программы все больше и больше тормозит. Как раз потому, что программисты думают, что выделение памяти бесплатно.


Да, выделение памяти в дотнете - это лишь перемещение одного указателя. Выделение памяти в нативной куче - гораздо более тяжеловесная операция.
Если объект был создан, и почти тут же удалён, то сборщик мусора может и не действовать при этом, поэтому не нужно его приплетать к каждому случаю.


Цитата: FiloXSee
Если бы ты пописал программы для устройств с ограниченной памятью


15 килобайт оперативки - достаточно мало? Писал под такое устройство очень много.
А начинал я программировать на устройстве с памятью 512 байт...


Цитата: FiloXSee
то тогда понял бы, что оперативная память - это одно из самых узких мест современной вычислительной техники.


Объём памяти или пропускная способность шины? ;)


Цитата: FiloXSee
Заполни какое нибудь TreeView десятью тысячами записей и когда у тебя будет столл в две секунды на "бесплатном выделение памяти", скажи, что я не прав.


Таки шо, это проблема C#? Или же это проблема создания большого количества объектов? То же самое будет в любом другом языке, в любой платформе. Да, пул может помочь. Вот только при чём тут наезд на сборщик мусора и управляемый код - хз.


И напоследок:
[QUOTE=MSDN]lock (this) может привести к проблеме, если к экземпляру допускается открытый доступ.[/QUOTE]


P.S. перл про фрагментирование памяти в дотнете уберите - засмеют...

65K
25 сентября 2011 года
FiloXSee
18 / / 01.07.2011
Учел некоторые пожелания.
5
25 сентября 2011 года
hardcase
4.5K / / 09.08.2005
Цитата: koodeer

P.S. перл про фрагментирование памяти в дотнете уберите - засмеют...


На самом деле фрагментация памяти в CLR вполне реальное явление, если, конечно, говорить о LOH - куче больших объектов - объекты в ней никуда не перемещаются и при длительной работе с большими массивами можно вполне получить OutOfMemoryExcption. Это еще один повод для перехода на x64 - там фрагментация памяти влияет меньше (да и JIT код получше выдает).

5
25 сентября 2011 года
hardcase
4.5K / / 09.08.2005
Цитата: FiloXSee

Заполни какое нибудь TreeView десятью тысячами записей и когда у тебя будет столл в две секунды на "бесплатном выделение памяти", скажи, что я не прав.


А зачем нужно заниматься этим идиотизмом? Для отображения большого количества объектов совсем не обязательно создавать аналогичное количество элементов интерфейса (которые, кстати, следует считать ресурсом). Поищите в сети про виртуальные списки, гриды и т.п. - идея заключается в том, чтобы создавать элементов интерфейса столько, сколько в данный момент времени видно/нужно пользователю.

5
25 сентября 2011 года
hardcase
4.5K / / 09.08.2005
Цитата: koodeer
Про unsafe в C# никогда не слышали?

На создание объектов и правда влиять не можем. Зато можем предсказать начало stop-world GC.

Цитата: koodeer
Выделение памяти в .NET - практически бесплатная операция.
Читайте про работу GC и управление памятью, прежде чем писать такое!

Если уж говорить о хардкорных оптимизациях, то правда - создание объектов перестает быть сравнительно "бесплатной" операцией, "бесплатной" она остается лишь для структур. В предельных случаях на производительность могут влиять слишком длинные цепочки вида x.PropA.PropB.PropC - излишняя косвенность оказывает существенное влияние на производительность: процессор тем и занимается что вычисляет адреса.

Цитата: koodeer

Дальше читать не стал.

+1 автору прежде чем публиковать опусы необходимо ознакомиться с существующем материалом, коего в интернетах достаточно (и, кстати, орфорграфию подтянуть немешало бы). Означенные оптимизации очевидны и общеизвестны, но вот код, как говорится, "без слез не взглянешь".

65K
25 сентября 2011 года
FiloXSee
18 / / 01.07.2011
Цитата:
А зачем нужно заниматься этим идиотизмом? Для отображения большого количества объектов совсем не обязательно создавать аналогичное количество элементов интерфейса (которые, кстати, следует считать ресурсом). Поищите в сети про виртуальные списки, гриды и т.п. - идея заключается в том, чтобы создавать элементов интерфейса столько, сколько в данный момент времени видно/нужно пользователю.


А можно ссылочку на подобное применение в C#. Я такое делал только в списках на iPhone.

297
04 октября 2011 года
koodeer
1.2K / / 02.05.2009
После непродолжительного отсутствия, я снова в теме.

Цитата: FiloXSee
Учел некоторые пожелания.


Посмотрел. Так мне нравится несколько больше.
Ма-а-аленькое замечание: фон для кода в виде тетрадного листочка в клеточку как-то слишком наводит на мысль о школе... школотизм, ага :). Но это моё субъективное мнение.


Цитата: hardcase
Для отображения большого количества объектов совсем не обязательно создавать аналогичное количество элементов интерфейса (которые, кстати, следует считать ресурсом). Поищите в сети про виртуальные списки, гриды и т.п. - идея заключается в том, чтобы создавать элементов интерфейса столько, сколько в данный момент времени видно/нужно пользователю.


Цитата: FiloXSee
А можно ссылочку на подобное применение в C#.


Я тоже хотел упомянуть про виртуализацию.
Вспомнилась вот эта тема: http://www.gotdotnet.ru/forums/3/137820/648992/ Посмотрите примеры кода Algol36 - миллион элементов - пустяк!
Что ещё могу вспомнить с ходу. Например, это: MSDN DataGridView.VirtualMode

297
04 октября 2011 года
koodeer
1.2K / / 02.05.2009
Цитата: hardcase
На самом деле фрагментация памяти в CLR вполне реальное явление, если, конечно, говорить о LOH - куче больших объектов - объекты в ней никуда не перемещаются и при длительной работе с большими массивами можно вполне получить OutOfMemoryExcption.


Эх, я когда штудировал работу с памятью в дотнете, так и не нашёл описания работы LOH. Везде пишут про кучу маленьких объектов, про то как GC её уплотняет и т. п. Также не нашёл толковых описаний, что будет, если объект зафиксировать в памяти (fixed): может ли это создать фрагментацию, как GC будет обходить этот "пришпиленный" кусок памяти?
Впрочем, я не шибко искал (хотя спрашивал - никто вроде не ответил).

Знаете кого-то, кто может ответить? Поделитесь с ним ссылкой.

Ваш ответ

Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог