Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>Наоборот, очень легко. Для хештейбла это всего 5000 элементов.
EP>Ну так а что у hashtable внутри? Не массив случайно?
Целых два.
EP>А что там сравнивать — у deque'и при random access на одну косвенность больше. Линейная итерация, если реализовывать максимально эффективно, то получается практически также
Какую задачу ты хочешь декой решить ? итерации по линкед лист и по какому нибудь полу-массиву практически одинаково стоят.
У деки преимущество не в рандомном доступе, а в сложности рандомного добавления, удаления. Покажи задачу, на которой ты хочешь профит получить.
Здравствуйте, Ikemefula, Вы писали:
EP>>Ну так а что у hashtable внутри? Не массив случайно? I>Целых два.
И как это опровергает:
EP>В этой Large Object Heap основные жители это массивы.
?
EP>>А что там сравнивать — у deque'и при random access на одну косвенность больше. Линейная итерация, если реализовывать максимально эффективно, то получается практически также
I>Какую задачу ты хочешь декой решить?
Аллокацию array-like данных в условиях фрагментации, топик разве не про это
Мне уже надоело объяснять тривиальные вещи, поэтому следующие два перла оставляю тебе на домашнее задание:
I>итерации по линкед лист и по какому нибудь полу-массиву практически одинаково стоят.
I>У деки преимущество не в рандомном доступе, а в сложности рандомного добавления, удаления.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>И как это опровергает: EP>
EP>>В этой Large Object Heap основные жители это массивы.
EP>?
А я где то написал опровержение ? Дай ссылку что ли
I>>Какую задачу ты хочешь декой решить?
EP>Аллокацию array-like данных в условиях фрагментации, топик разве не про это
Они все разные, array-like данные. Если не критично удаление-добавление по индексу, то от деки толку мало. То есть, выбирать структуры для оптимизации нужно под конкретные сценарии в приложении, а не руководствуясь соображениями о прекрасном.
Скажем для многих вещей сгодится какой нибудь BigList или ScanList из powercollections, а если в циклах тяжелые вычисления, то и вовсе сгодится разреженный массив на основе дерева.
Здравствуйте, Ikemefula, Вы писали:
I>Я уже рассказывал, но ты же не читатель.
Это ты не читатель. Я же уже писал тут, что пока что складывается такое впечатление, что С#-разрабы в массе своей не смогли разобраться в причинах проблемы и просто перестали использовать большие вектороподобные коллекции
Пока что ты это только подтверждаешь...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Речь идёт про загаживание LOH большими объектами, с которым дела обстояли плохо вплоть до VS2008. НС>>Стоит начать хотя бы с понимания того факта, что рантайм (и поведение GC) от версии студии практически никак не зависит.
EP>Это очень важный факт, который меняет в корне всю дискуссию. Когда делал примеры — выбирал максимально доступный Runtime. EP>Расскажи лучше как в VS2008 выбрать .NET 4.0
Ты определись, чего хочешь, скомпилить код или проверить код под конкретным рантаймом ?
Если первое, то это к доктору. Если второе, то компилится ОДИН РАЗ хоть для .Net 1.0 и дальше переключаешь рантайм в манифесте. Я совсем недавно обнаружил, что часть прекомпиленых сборок никто не билдил ажно с 2003го года, это .Net 1.1
И это, представь, на флагманском продукте который зарабатывал основные деньги для всей компании.
Пойми простую вещь, если код компилится в древней вижле, то это вовсе не значит, что работать он будет под тем же древним рантаймом. Большей частью наоборот, а вижла нужна только для того, что бы какой нибудь экзотический компилер поднять, которой микрософт перестала майнтейнить, навроде J#.
EP>>В этой Large Object Heap основные жители это массивы.
EP>>Как я понял, Large Object в виде структуры/класса при пороге 85kB получить крайне трудно. Особенно учитывая то, что fixed-size массивы там крайне неудобные (только unsafe context).
I>Наоборот, очень легко. Для хештейбла это всего 5000 элементов.
I>>>Какую задачу ты хочешь декой решить? EP>>Аллокацию array-like данных в условиях фрагментации, топик разве не про это I>Они все разные, array-like данные. Если не критично удаление-добавление по индексу, то от деки толку мало.
Какая сложность добавления элемента в центр std::deque?
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>Возможно... Но мне даже трудно представить задачу, когда нам нужно десятки/сотни миллионов элементов в линейном массиве. НС>Сочувствую, чо.
Ну я типа ждал ЛЮБОГО примера, чтобы показать, что линейный массив для него не нужен. )))
Здравствуйте, Ikemefula, Вы писали:
EP>>Ты лучше ответь на вопрос который в самом верху. I>Ты лучше сформулируй проблему, которую хочешь решить. С вероятностью 99% НС уже дал исчерпывающий ответ.
Здравствуйте, Erop, Вы писали:
E>Это ты не читатель. Я же уже писал тут, что пока что складывается такое впечатление, что С#-разрабы в массе своей не смогли разобраться в причинах проблемы и просто перестали использовать большие вектороподобные коллекции
Никто никогда не переставал. Где то в 20% приложений такие коллекции дают проблемы и как то люди справлялись, не думаешь ли ты, что только я один умный, смог забороть в проекте эту фрагментацию ?
Кроме того, там где нужны большие вектороподобные коллекции, C# гарантировано сливает нативным плюсам в большинстве сценариев. Подумай головой — дотнетчики они почти все бывшие плюсовики, что еще они могли заюзать ?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Ты лучше ответь на вопрос который в самом верху. I>>Ты лучше сформулируй проблему, которую хочешь решить. С вероятностью 99% НС уже дал исчерпывающий ответ.
EP>Поясни как вот это
относится к обсуждаемой проблеме и приведённым примерам. И как бы возможность смены рантайма помогла бы всем этим людям в своё время.
Объясняю — ты не раз и не два писал "а вон в той вижле GC не так работает"
А потом попросил совета, как сбилдить прожку не под той вижлой, очевидно, для проверки LOH
Не нужно ничего билдить в разных вижлах, правишь манифест, а билди хоть вижлой 2002го года один раз на все случаи жизни.
Всем этим людям смена вижлы не поможет никак — версия вижлы не влияет на ГЦ и рантайм.
Этим людям поможет
1. профайлер
2. /dev/brain
3. Новый GC
относится к обсуждаемой проблеме и приведённым примерам. И как бы возможность смены рантайма помогла бы всем этим людям в своё время. I>Объясняю — ты не раз и не два писал "а вон в той вижле GC не так работает" I>А потом попросил совета, как сбилдить прожку не под той вижлой, очевидно, для проверки LOH I>Не нужно ничего билдить в разных вижлах, правишь манифест, а билди хоть вижлой 2002го года один раз на все случаи жизни.
У меня есть все VS начиная с 2005, и мне не трудно прогнать тест в каждой
I>Всем этим людям смена вижлы не поможет никак — версия вижлы не влияет на ГЦ и рантайм.
Видишь дату вопроса? Каким образом они могли бы использовать .NET 4.0 или .NET 4.5 в 2009 году
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>>В этой Large Object Heap основные жители это массивы. EP>>>[/q] EP>>>? I>>А я где то написал опровержение ? Дай ссылку что ли
EP>http://rsdn.ru/forum/flame.comp/5335848.1
EP>>>В этой Large Object Heap основные жители это массивы.
EP>>>Как я понял, Large Object в виде структуры/класса при пороге 85kB получить крайне трудно. Особенно учитывая то, что fixed-size массивы там крайне неудобные (только unsafe context).
I>>Наоборот, очень легко. Для хештейбла это всего 5000 элементов.
Так здесь совсем другое, вот класс хештейбла, он спокойно войдет в LOH при определнном размере Или ты имеешь ввиду одним куском шоб сразу все было ? Не совсем ясно, для чего это нужно
EP>>>Аллокацию array-like данных в условиях фрагментации, топик разве не про это I>>Они все разные, array-like данные. Если не критично удаление-добавление по индексу, то от деки толку мало.
EP>Какая сложность добавления элемента в центр std::deque?
Ты лучше сразу напиши, с чем ты не согласен, а то я устал уже. Если вставка-удаление в деку хуже константы, то дека никому не нужна. В моей реализации — константа.
Типичный сценарий — удалить надо 1000...100000 элементов по индексу. Если структура линейная, то это фейл с лагами чуть не в минутах. Я на этом сэкономил с 6 часов до 5 минут, одной только декой.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>Не нужно ничего билдить в разных вижлах, правишь манифест, а билди хоть вижлой 2002го года один раз на все случаи жизни.
EP>У меня есть все VS начиная с 2005, и мне не трудно прогнать тест в каждой
Если тебе нравится работать руками, так работай руками, зачем тебе советы ?
I>>Всем этим людям смена вижлы не поможет никак — версия вижлы не влияет на ГЦ и рантайм.
EP>Видишь дату вопроса? Каким образом они могли бы использовать .NET 4.0 или .NET 4.5 в 2009 году
А ты читай, в самом начале говорится про .Net 4, более того, там указано, что вижла была 2010 бета 2.
Здравствуйте, Ikemefula, Вы писали:
I>>>Всем этим людям смена вижлы не поможет никак — версия вижлы не влияет на ГЦ и рантайм. EP>>Видишь дату вопроса? Каким образом они могли бы использовать .NET 4.0 или .NET 4.5 в 2009 году I>А ты читай, в самом начале говорится про .Net 4, более того, там указано, что вижла была 2010 бета 2.
Ну значит всё ещё хуже, и хотя тест VS2010 выше показал небольшое улучшение (почти всю память смогла выделить только аж VS2012), видимо на реальных приложениях было всё ещё печально
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>А ты читай, в самом начале говорится про .Net 4, более того, там указано, что вижла была 2010 бета 2.
EP>Ну значит всё ещё хуже, и хотя тест VS2010 выше показал небольшое улучшение (почти всю память смогла выделить только аж VS2012), видимо на реальных приложениях было всё ещё печально
Здравствуйте, Ikemefula, Вы писали:
I>Так здесь совсем другое, вот класс хештейбла, он спокойно войдет в LOH при определнном размере
Весь хештейбл, или только массив?
I>Или ты имеешь ввиду одним куском шоб сразу все было ? Не совсем ясно, для чего это нужно
Ещё раз, ты что хотел вот тут сказать:
EP>>>>В этой Large Object Heap основные жители это массивы.
EP>>>>Как я понял, Large Object в виде структуры/класса при пороге 85kB получить крайне трудно. [...]
I>>>Наоборот, очень легко.[...]
Как часто в LOH будут находится обычные классы/структуры, а не какие-нибудь массивы?
EP>>>>Аллокацию array-like данных в условиях фрагментации, топик разве не про это I>>>Они все разные, array-like данные. Если не критично удаление-добавление по индексу, то от деки толку мало. EP>>Какая сложность добавления элемента в центр std::deque? I>Ты лучше сразу напиши, с чем ты не согласен, а то я устал уже. Если вставка-удаление в деку хуже константы, то дека никому не нужна.
Тем не менее проблему аллокации array-like данных в условиях фрагментации она решает
I>В моей реализации — константа.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Ну вот например соединение с базой данных — эта такая абстракция которая течёт из native'а?
На мой взгляд — да.
EP>>>Детерминизм действительно важен, и поэтому в C# есть using, в Java — try-with-resources , в Python — with — и везде требуется подобие IDisposable.
Довольно часто на форумах встречается вопрос, почему не работает такой код:
public SomeDisposableType foo() {
using(var some = new SomeDisposableType())
return some;
}
В данном примере объект диспозится ещё до того, как будет возвращён. А если убрать using, то диспозить его нужно вручную. Причём можно и не вызывать диспоз вручную, тогда объект удалится финализатором, но недетерминированно, неизвестно когда. А я считаю, что вполне можно создать такой механизм, который будет удалять объект сразу же, как только он будет использован в последний раз. Только и всего.
