Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Например таких?
EP>

EP>using (var connection = new SqlConnection(connectionString))
EP>{
EP>    // ...
EP>    foo_may_throw();
EP>    // ...
EP>}
EP>

В данном случае используется неуправляемый ресурс — коннекшн к БД. Вот для его корректного освобождения и нужен диспоуз.

Здравствуйте, koodeer, Вы писали:

K>>>Dispose-костыли в управляемой среде предназначены в основном для решения проблем с нативным кодом.
EP>>Например таких?
EP>>

EP>>using (var connection = new SqlConnection(connectionString))
EP>>{
EP>>    // ...
EP>>    foo_may_throw();
EP>>    // ...
EP>>}
EP>>

K>В данном случае используется неуправляемый ресурс — коннекшн к БД. Вот для его корректного освобождения и нужен диспоуз.

А сколько по-твоему "управляемых" ресурсов? И все ли неуправляемые ресурсы как-то связанны с нативным кодом, или всё-таки большинство существуют сами по себе?

Здравствуйте, Erop, Вы писали:

A>>эм... вообще-то доказательством работоспособности может быть только (юнит)тест

E>Про проблему останова слыхал? Так вот, одно из следствий состоит в том, что никакой тест не может гарантировать работоспособности. Но в некоторых случаях некоторые специально написанные алгоритмы можно доказать ФОРМАЛЬНО, это если требуется такой уровень надёжности.

проблема останова это конечно сильный аргумент, но на практике почти весь код можно протестировать.
собственно мы все работаем не над сферическими алгоритмами в вакууме, а над конкретными программами, с конкретным набором фич.
эти фичи практически всегда можно протестировать вручную, а можно протестировать автоматически.

Здравствуйте, Erop, Вы писали:

E>Я, кстати, часто распечатки вообще читаю, ну, например, выхожу из дома в лес, сажусь на пинёк и читаю, что там у нас такого интересного напрограммировалось, что всё так неожиданно плохо...

купи планшет, дешевле будет чем бумагу и картриджи переводить.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>Элементарно — на добавление N элементов надо будет переместить N элментов в АП

EP>Подробнее.

Все предельно просто — случай когда количество всех объектов сильно зависит от этого N, например, добавляем тупо новые объекты, длина списка так же зависит от N.
Соответсвенно при наличии фрагментации нужно будет бегать по всему графу объектов, так как GC заранее не знает, что ему делать. Это уже само по себе N * log(N) если считать только сами объекты без ссылок на них, т.к. количество аллокаций только для списка это log(N). Перемещать нужно будет так же количество элментов, которое зависит от N, хоть и слабее и это будет или N или log(N). + если в дело вступит своп, то это бедствие. Выглядит на UI примерно так — приложение морозит полчаса и потом работает какое то время нормально, а иногда и дохнет от ООМ.


EP>>>2. Миллионный List из Point3D — это тоже ужас-ужас в квадрате?
I>>Не в курсе что это такое

EP>Структура с тремя double.

Это 50мб данных одним окном. В большом приложении на х32 это уже проблемный размер.

Здравствуйте, Erop, Вы писали:

E>Я, кстати, часто распечатки вообще читаю, ну, например, выхожу из дома в лес, сажусь на пинёк и читаю, что там у нас такого интересного напрограммировалось, что всё так неожиданно плохо...

Я ж говорю — колхоз. Есть вещи более эффективные нежели твои бумажки.

Здравствуйте, Erop, Вы писали:

I>>Не надо ничего размножать — доки находятся в единственном экземпляре на сервере в вики, конфлюэнце или шарепоинте. Надо модифировать фичу — берешь за основу старую версию, копируешь в фолдер новой версии и пишешь туда все что тебе надо.

E>Это и есть размножать... Если потом понадобится ещё и мержить правки в коде, то надо будет не забыть смёржить и доки, да ещё и сделать это корректно, кстати...

А если требования в коде, то их смержить код сохранив корректные каменты это задача практически нереальная, ибо надо заранее планировать каменты так что бы они не мешали мержу. А то будет вот так — ктото перенес функцию в отдельный файл, а при мерже получится так что структура каментов отличается от структуры нового кода.

I>>Для наукоемкой особенно актуальна интеграция VCS, трекера и документации, иначе вспотеешь контролировать все вырожденые случаи. для тупо технического проекта вообще никакой документации может не быть, потому что как правило все и так в теме или все есть в гугле.

E>Ну кто потеет, а кто без проблем контролирует...

Да, я в курсе. У меня есть один знакомый, который очень любит ручную работу. Он на почасовой оплате, смержит руками мегабайт кода за неделю, ему эту недели и оплатят.

I>>Мелкие вещи тоже надо тестировать. Объясни, каким раком тестировщики смогут покрыть твою мульку ручными/автоматическими тестами ?

E>Это никак не связано с тем, что ты где-то должен объяснить поддерживающим код коллегам ПРИЧИНЫ принятых в коде решений...

Ты похоже вообще в ИТ не работаешь. Документация даже мелких изменений должна быть вне кода, ибо не ты один работаешь с кодом. Тестеры, менеджеры, аналитики будут вынуждены пахать твой код, что бы разобраться ,что же ты там научитывал.

E>Про тестировать -- тема отдельная.

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

Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>Представь — есть 1гб список и АП 2гб, условно — больше никто не юзает память и АП. Выделяешь список с капасити 1гб, делаешь реверс и отдыхаешь. Вот больше 1гб не получится и вот это уже НЕ фрагментация, а тупо нехватка памяти. Все что сваливается меньше 1гб это фрагментация.

EP>[ | | | | | | | | | | | | | |*|*|*|*|*|*|*|*]
EP>* — занятное List'ом, пробел — свободное.
EP>Попробуй увеличь capacity вдвое — и покажи где тут фрагментация

Объясняю еще раз — если задаешь правильный капасити не надо ничего увеличивать. Надо 1гб — поставь точно такой же капасити, реаллокаций не будет, а следовательно GC не надо будеть гонять объекты по АП.


EP>>>Где это было, в какой среде? Случаем не в C# <=VS2008?
I>>Начиная с TP5.5-BP7.0, потом TC2.0-BC3.1, Watcom C, потом VS 97 и заканчивая VS 2012, примерно так Вот на ассемблере этого не было, динамику как то не сильно использовал, извини.

EP>Ты же про C# говорил

Автор: Ikemefula
Дата: 10.10.13

и его списки? Зачем про Паскаль загоняешь?

Потому что фрагментация вылазит всегда и везде, когда потребление памяти близко к размеру АП. Когда софт дорастет до границ х64, то там тоже вылезет проблема с фрагментацией. Радикально решить можно будет толко увеличением АП, то есть, переходом на 128 бит, а потом на 256 и так далее. Правда, есть шанс, что солнце погаснет раньше, чем мейнстрим дорастет до такой разрядности.

I>>Там про GC вообще, а не конкретный.

EP>А зачем не про конкретный, если топик начался с конкретных List'ов и конкретного C#'а?

Это что бы ты понял, про что речь и не лез ко мне с дурацкими аргументами про 3 и вектор.

EP>Не, не прокатит отмазка. У вектора grow factor не оговорен стандартом

Я не в курсе стандартов, вы его тут указали как 1.5, вот от него и считаю. А у тебя снова получается, что grow factor какой то очень удобный — 1.5, 2, "не оговорен стандартом", очень удобный аргумент.

EP>А твой ответ показывал полное не понимание:
EP>

V>>>Если в тесте после грубо 660 метров не удалось выделить память, то это значит, что всего было запрошено порядка 660*3=1980 метров. ЧТД.
i>>А почему на три надо помножать, если добавляем по одному байту ?

EP>Тут нет ничего про 1.5x, тут есть "добавляем по одному байту"

Это специально для vdimas. Я ожидал от него чтото навроде "Ага ! Попался, двоечник !!! байты ни при чем !!!!111расрас" и на тот момент у меня был заготовлен более интересный троллинг

Здравствуйте, Ikemefula, Вы писали:

EP>>Подробнее.

I>Все предельно просто — случай когда количество всех объектов сильно зависит от этого N, например, добавляем тупо новые объекты, длина списка так же зависит от N.
I>Соответсвенно при наличии фрагментации нужно будет бегать по всему графу объектов, так как GC заранее не знает, что ему делать. Это уже само по себе N * log(N) если считать только сами объекты без ссылок на них, т.к. количество аллокаций только для списка это log(N). Перемещать нужно будет так же количество элментов, которое зависит от N, хоть и слабее и это будет или N или log(N). + если в дело вступит своп, то это бедствие. Выглядит на UI примерно так — приложение морозит полчаса и потом работает какое то время нормально, а иногда и дохнет от ООМ.

Я чучка погорячился про квадратичность, но сути это не меняет. N*log(N) с подключением свопа мало чем отличается для обсуждаемого размера АП.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>А сколько по-твоему "управляемых" ресурсов? И все ли неуправляемые ресурсы как-то связанны с нативным кодом, или всё-таки большинство существуют сами по себе?

Точные оценки давать не берусь.
Проблема в том, что управляемый код работает поверх неуправляемого. Это никак не исправить. Поэтому костыли Dispose.
Вот если бы стала мейнстримом ОС наподобие Singularity, изначально разрабатывавшаяся на управляемой платформе, вот там вполне могло бы не быть таких проблем. Но это из области фантастики.

Здравствуйте, Ikemefula, Вы писали:

I>>>Элементарно — на добавление N элементов надо будет переместить N элментов в АП
EP>>Подробнее.
I>Все предельно просто — случай когда количество всех объектов сильно зависит от этого N, например, добавляем тупо новые объекты, длина списка так же зависит от N.
I>Соответсвенно при наличии фрагментации нужно будет бегать по всему графу объектов, так как GC заранее не знает, что ему делать. Это уже само по себе N * log(N) если считать только сами объекты без ссылок на них, т.к. количество аллокаций только для списка это log(N).

При push_back'е элемент за элементом, без предварительного reserve сложность получается O(N).
Например, нужно 16 элементов, grow factor=2:
1
2
4
8
16
На каждой реаллокации происходит пробежка по все текущим элементам (это либо copy/move constructor в C++, либо Mark у GC — не суть).
Числа выше сможешь просуммировать?

I>Перемещать нужно будет так же количество элментов, которое зависит от N, хоть и слабее и это будет или N или log(N). + если в дело вступит своп, то это бедствие. Выглядит на UI примерно так — приложение морозит полчаса и потом работает какое то время нормально, а иногда и дохнет от ООМ.

Ты не то что "практически N^2", а даже O(N * log(N)) не показал

EP>>>>2. Миллионный List из Point3D — это тоже ужас-ужас в квадрате?
I>>>Не в курсе что это такое
EP>>Структура с тремя double.
I>Это 50мб данных одним окном. В большом приложении на х32 это уже проблемный размер.

В структуре 3*8 байт, миллион структур. Откуда 50MB нарисовались?

Здравствуйте, Ikemefula, Вы писали:

I>Я чучка погорячился про квадратичность, но сути это не меняет. N*log(N) с подключением свопа мало чем отличается для обсуждаемого размера АП.

Ну ты даже O(N*log(N)) не показал. То о чём ты говоришь это O(N).

Здравствуйте, koodeer, Вы писали:

K>Проблема в том, что управляемый код работает поверх неуправляемого. Это никак не исправить. Поэтому костыли Dispose.
K>Вот если бы стала мейнстримом ОС наподобие Singularity, изначально разрабатывавшаяся на управляемой платформе, вот там вполне могло бы не быть таких проблем. Но это из области фантастики.

И что, в такой OS не будет файлов, мьютексов, соединений?

Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>Я чучка погорячился про квадратичность, но сути это не меняет. N*log(N) с подключением свопа мало чем отличается для обсуждаемого размера АП.

EP>Ну ты даже O(N*log(N)) не показал. То о чём ты говоришь это O(N).

O(log(N)) аллокаций массива в списке, для каждой из них надо пробежать граф из O(N) элементов

Сколько это по твоему ?

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Числа выше сможешь просуммировать?

Я уже две недели по 12 часов без выходных работаю

EP>>>Структура с тремя double.
I>>Это 50мб данных одним окном. В большом приложении на х32 это уже проблемный размер.

EP>В структуре 3*8 байт, миллион структур. Откуда 50MB нарисовались?

У меня в проекте аналогичные структуры выровнены на границу 16 байт Ну будет 24мб если что, это попроще, но тоже не факт ,что всегда будет такое окно.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>Я чучка погорячился про квадратичность, но сути это не меняет. N*log(N) с подключением свопа мало чем отличается для обсуждаемого размера АП.

EP>Ну ты даже O(N*log(N)) не показал. То о чём ты говоришь это O(N).

Кстати, GC будет дергаться даже во время размещения новых элементов. Не сильно в курсе, как происходит переход из поколения в поколение, но факт, что GC будет вызываться чаще чем log(N)

Здравствуйте, Ikemefula, Вы писали:

I>>>Я чучка погорячился про квадратичность, но сути это не меняет. N*log(N) с подключением свопа мало чем отличается для обсуждаемого размера АП.
EP>>Ну ты даже O(N*log(N)) не показал. То о чём ты говоришь это O(N).
I>O(log(N)) аллокаций массива в списке, для каждой из них надо пробежать граф из O(N) элементов
I>Сколько это по твоему ?

Выделенное неверно.
Аллокаций действительно O(log(N)), вот только на каждой нужно пробежать по количеству зависящему от номера текущей аллокации, а не от общего числа элементов.
Без разницы, что ты добавляет 128 элементов, что 65536 — на первых реалокациях (допустим на первых 6) — нужно пробежать одинаковое колличество элементов, независящее от N.

Суммарная дистанция пробега для заполнения N элементами будет суммой первых O(log(N)) членов геометрической прогрессии:
(1 — grow_factor^( log(N)/log(grow_factor) )) / (1 — grow_factor)
если упростить степень, то останентся: (1 — N) / (1 — grow_factor)
то есть O(N).

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>И что, в такой OS не будет файлов, мьютексов, соединений?

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

Здравствуйте, koodeer, Вы писали:

EP>>И что, в такой OS не будет файлов, мьютексов, соединений?
K>Я полагаю, в изначально управляемой среде их можно сделать такими, что среда будет полностью отслеживать их использование, и автоматически удалять/закрывать/освобождать.

Ну а что, например, делать с мьютексом? Ждать пока система его разлочит?
А если там какая-нибудь синхронизация чуть сложнее тривиальной — один мьютекс система отпустит, а другой нет, и внезапно наступает deadlock

K>Я полагаю, в изначально управляемой среде их можно сделать такими, что среда будет полностью отслеживать их использование, и автоматически удалять/закрывать/освобождать.

Или например как создавать свои ресурсы? Как сказать системе что делать при их закрытии?