Здравствуйте, Mr.Cat, Вы писали:
U>>Хорошо. Вы можете привести пример в котором код написанный в финализаторе или Dispose выполнялся бы быстрее нативного при условии что выполняются одни и те-же действия? MC>При чем тут быстрее/медленнее?
Речь шла изначально о скорости, но вам похоже важнее выяснить как оно называется. MC> Я и мои коллеги просто указываем Вам на то, что финализатор и деструктор — не одно и то же, с чем Вы вроде как не согласны.
Есть некий механизм финализации объекта который состоит из двух фаз:
1) когда объект больше не нужен производятся некие действия.
2) память зарезервированная под объект освобождается.
Где-то он называется деструктор, где-то развесистая комбинация финализатора + dispose + GC. Пусть слова "деструктор" там нет, но по сути выполняют эти механизмы одну и ту-же функцию. Меня не волнует какими словами этот механизм обозван, хоть транклюкатор. Тем более в Delphi.NET он так и называется — деструктор, хотя разворачивается именно в вышеописанный набор вещей.
Не уж-то вы услышав слово "деструктор" не поняли о чем речь? По моему прекрасно поняли.
U>>Естественно вместе с GC.Collect, потому как объектов много и память физическая нужна сейчас, а не когда-нибудь. MC>Очень рекомендую Вам почитать про работу GC, в частности, в .NET, чтобы таких вопросов не возникало. GC.Collect вызывать руками вовсе не нужно — если памяти под новый объект не хватает — сборка будет произведена. А если хватает — то лишние сборки ни к чему.
Ну измените количество объектов в большую сторону, сделайте удаления части объектов, потом снова распределение и т.п. Так и быть, GC.Collect не нужно будет писать. Оно будет вызываться само собой и всё равно сожрет CPU, хотя есть шанс что сожрет ресурсы другого ядра. У моего CPU их четыре, но на машине пользователя может быть и одно.
Поясню ближе к практике. У меня есть некий процесс, результатом выполнения которого является сложная динамическая структура. Структура состоит из неопределенного количества объектов — порядок деятки, сотни тысяч, миллионы объектов. Эта структура может создаваться как результат некоего процесса, сохраняться в БД (в БД этих структур естественно может быть не одна), загружаться оттуда, части её могут модифицироваться или удаляться, причем удаляться именно в памяти чтобы сгенерироваться снова из базы или из процесса. Меня волнует вопрос, насколько быстро это всё будет происходить. Делаем простой тест — распределяем миллион (два, десять) объектов и видим что не смотря на заявления про супер быстрый манагер памяти, про то что кто-то там генерит код более быстрый чем нативный Delphi, реально объекты были созданы существенно медленнее. С удалением объектов картина очень похожая.
Здравствуйте, Utruk, Вы писали: U>Речь шла изначально о скорости, но вам похоже важнее выяснить как оно называется.
Да. Я вообще последнее время не увлекаюсь бесполезными бенчмарками. В 99% случаев узким местом будет БД, сеть, какие-нибудь внешние библиотеки (например, для математических расчетов) или пользователь. Так что разницы в производительности особо никто не заметит.
U>Есть некий механизм финализации ... по сути выполняют эти механизмы одну и ту-же функцию.
Цель-то конечно одна — ресурсы корректно освободить. А вот техническая реализация совершенно разная.
U>миллионы объектов ... сохраняться в БД
Вот работа с БД и будет занимать большую часть времени. Так что займитесь лучше оптимизацией запросов, а приложение можете хоть на питоне написать.
Здравствуйте, Utruk, Вы писали:
U>Где-то он называется деструктор, где-то развесистая комбинация финализатора + dispose + GC. Пусть слова "деструктор" там нет, но по сути выполняют эти механизмы одну и ту-же функцию.
Тебе же сказали RTFM. Автоматическая сборка мусора предполагает недетерменированный момент удаления объектов из кучи.
Dispose это вообще из другой оперы. Всего-лишь механизм для принудительного освобождения системных ресурсов (файлы, соединения к БД и т.п.) и хотя Dispose вызывается в финализаторе, но обычно предполагает принудительный вызов. Например, автоматически при выходе из блока using() { } или вручную в блоке try ... finally { }.
U>Поясню ближе к практике.
Описанная тобой ситуация не имеет никакого отношения к практике.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, Utruk, Вы писали:
U>>Где-то он называется деструктор, где-то развесистая комбинация финализатора + dispose + GC. Пусть слова "деструктор" там нет, но по сути выполняют эти механизмы одну и ту-же функцию. kuj>Тебе же сказали RTFM. Автоматическая сборка мусора предполагает недетерменированный момент удаления объектов из кучи.
И???? Память-то мой процесс получит быстрее или как? Ему как бы работать надо, а не ждать пока этот самый недетерминированный момент случится.
kuj>Dispose это вообще из другой оперы. Всего-лишь механизм для принудительного освобождения системных ресурсов (файлы, соединения к БД и т.п.) и хотя Dispose вызывается в финализаторе, но обычно предполагает принудительный вызов. Например, автоматически при выходе из блока using() { } или вручную в блоке try ... finally { }. U>>Поясню ближе к практике. kuj>Описанная тобой ситуация не имеет никакого отношения к практике.
Шеф, вы?
Здравствуйте, diatlov, Вы писали:
D>НЕТ! Я конечно не самый лучший программист.. но программа была запущена С ЖЕСТКОГО ДИСКА, НЕ С СЕТЕВОГО.
Значит в полиси была фигня накручена, что даже для сборок на локальном диске full trust не выдавался. С caspol кто то, небось, поигрался.
D> Я на кривость не валил, я сказал лишь что trustы иногда мешают. Ну т.е. они конечно не мешают, а даже наоборот, НО когда ты все время писал нативный код и привык что экзешник работает с полпинка, то после этого морочится тем о чем написал Константин.. короче надо привыкать к этому.
Ни с чем морочится не надо, если не лезть туда, куда не понимаешь.
Здравствуйте, Utruk, Вы писали:
НС>>Я в этом не уверен.
U>Посмотрите сами.
Нет ни возможности ни желания.
U>>>, соответственно разница может быть в оверхеде который накладывает .NET исходящим из особенностей его функционирования.
НС>>Вывод неверный.
U>Аргументируйте.
Уже, просто ты упорно игнорируешь. Чтобы добится замедления обращения к БД даже в скриптах, надо конкретно накосячить. А что именно и где накосячили, мне мало интересно. Бери ODP или хотя бы нативный провайдер и меряй. Я для MSSQL мерял, разница, разумеется, ничтожна.
Здравствуйте, Utruk, Вы писали:
U>>>Где-то он называется деструктор, где-то развесистая комбинация финализатора + dispose + GC. Пусть слова "деструктор" там нет, но по сути выполняют эти механизмы одну и ту-же функцию. kuj>>Тебе же сказали RTFM. Автоматическая сборка мусора предполагает недетерменированный момент удаления объектов из кучи.
U>И???? Память-то мой процесс получит быстрее или как? Ему как бы работать надо, а не ждать пока этот самый недетерминированный момент случится.
Твоему процессу памяти не хватает? Может пора равнять руки?
Здравствуйте, Mr.Cat, Вы писали:
U>>Речь шла изначально о скорости, но вам похоже важнее выяснить как оно называется. MC>Да. Я вообще последнее время не увлекаюсь бесполезными бенчмарками. В 99% случаев узким местом будет БД, сеть, какие-нибудь внешние библиотеки (например, для математических расчетов) или пользователь. Так что разницы в производительности особо никто не заметит. U>>Есть некий механизм финализации ... по сути выполняют эти механизмы одну и ту-же функцию. MC>Цель-то конечно одна — ресурсы корректно освободить. А вот техническая реализация совершенно разная. U>>миллионы объектов ... сохраняться в БД MC>Вот работа с БД и будет занимать большую часть времени. Так что займитесь лучше оптимизацией запросов, а приложение можете хоть на питоне написать.
Тезис был "Delphi лучше C# потому что быстрее"... начиналось всё с "увеличения указателя и пары проверок", теперь уже "пооптимизируйте в других местах". В "других местах" оно даст эффект и с нативным приложением, тут заслуги сишарпа с дотнетом никакой.
Здравствуйте, Utruk, Вы писали:
U>Тезис был "Delphi лучше C# потому что быстрее"... начиналось всё с "увеличения указателя и пары проверок", теперь уже "пооптимизируйте в других местах". В "других местах" оно даст эффект и с нативным приложением, тут заслуги сишарпа с дотнетом никакой.
Производительность имеет значение только тогда, когда ее не хватает. Вот наш проектик обслуживает примерно 7000-8000 подключений за сутки. Жалоб на производительность нету.
Глобальное преимущество .NET и Java — удобство и скорость разработки. Покажи мне нормальные аналоги для Castle Windsor, MEF, ASP.NET MVC, nHibernate, Rhino Mocks, nServiceBus и т.д. и т.п и покажи мне средства для организации полноценного continuous integration процесса...
Delphi как была никчемной игрушкой для бедных ВУЗов и энтузиастов этого уродства под названием "delphi language", так ею и осталась.
Здравствуйте, Utruk, Вы писали:
U>Здравствуйте, kuj, Вы писали:
kuj>>Здравствуйте, Utruk, Вы писали:
U>>>Где-то он называется деструктор, где-то развесистая комбинация финализатора + dispose + GC. Пусть слова "деструктор" там нет, но по сути выполняют эти механизмы одну и ту-же функцию. kuj>>Тебе же сказали RTFM. Автоматическая сборка мусора предполагает недетерменированный момент удаления объектов из кучи.
U>И???? Память-то мой процесс получит быстрее или как?
Вашему процессу не хватает памяти, вы хотите об этом поговорить?
U>Ему как бы работать надо, а не ждать пока этот самый недетерминированный момент случится.
Нет, если память понадобится, то GC для вас найдет кусочек.
Здравствуйте, kuj, Вы писали:
U>>И???? Память-то мой процесс получит быстрее или как? Ему как бы работать надо, а не ждать пока этот самый недетерминированный момент случится.
kuj>Твоему процессу памяти не хватает? Может пора равнять руки?
Память ресурс не бесконечный. Бывает его занимают другие процессы. Бывает его просто мало. Бывает его требуется много. Бывают задачи в которых скорость критична.
Например одна из задач которых у меня есть должна обрабатывать картинки. Картинки формата от A5 до A3 с разрешением в 300..600 dpi и цветностью от B/W до True Color прилетают со частотой 2..3 страницы в секунду. За это время надо успеть её обработать (проверить не белая-ли, не загнутые ли углы, нет ли там баркода, не грязная ли ну и т.п.) и положить на хранение. Пока удается укладываться. Медленнее нельзя, при тех объемах которые есть даже 10% процентные тормоза становятся заметными, это уже деньги... Вот я и думаю, если у меня программа будет на C# а не на Delphi, я смогу сохранить скорость?
Здесь люди утверждают что сишарповский компилятор генерит код который выполняется быстрее чем дельфийский нативный. Простой пример с распределением миллиона объектов заставляет меня усомниться в этом. Страшно подумать что будет когда пример станет сложным и распределение каждого объекта будет сопровождаться распределением 30-ти метров памяти плюс обвешан всякими обработками переписанными на С#. Я конечно понимаю что можно заапгрейдить железо, но скажем какая-нибудь индонезийская или японская почта просто не поймет меня и вежливо покивав головой, "о да, ваша карасо, мы вам позвонить", пойдет искать а нет ли кого-то кто не требует апгрейда железа.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Уже, просто ты упорно игнорируешь. Чтобы добится замедления обращения к БД даже в скриптах, надо конкретно накосячить. А что именно и где накосячили, мне мало интересно. Бери ODP или хотя бы нативный провайдер и меряй. Я для MSSQL мерял, разница, разумеется, ничтожна.
Я мерял для Oracle. Разница не ничтожна. Ну и надеюсь под "обращением к БД" подразумевается не только выполнение SQL запроса, но и скажем чтение данных из рекордсета, а так-же распихивание их по внутренним структурам программы.
Тесты то запускали, али на стебе над % все остановилось?
Здравствуйте, gandjustas, Вы писали:
U>>И???? Память-то мой процесс получит быстрее или как? G>Вашему процессу не хватает памяти, вы хотите об этом поговорить?
Нет. Я хочу поговорить о том с какой скоростью мой процесс будет получать очередную серию кусков памяти. С этого всё начиналось. Меня вполне удовлетворит если это случиться быстрее чем на Delphi.
Здравствуйте, Utruk, Вы писали:
U>Я мерял для Oracle. Разница не ничтожна.
Вот я и говорю — ищи косяки в Дельфи.
U> Ну и надеюсь под "обращением к БД" подразумевается не только выполнение SQL запроса, но и скажем чтение данных из рекордсета, а так-же распихивание их по внутренним структурам программы.
Если это распихивание дольше самого запроса, то нет, не подразумевается.
U>Тесты то запускали, али на стебе над % все остановилось?
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, Utruk, Вы писали:
U>>Тезис был "Delphi лучше C# потому что быстрее"... начиналось всё с "увеличения указателя и пары проверок", теперь уже "пооптимизируйте в других местах". В "других местах" оно даст эффект и с нативным приложением, тут заслуги сишарпа с дотнетом никакой.
kuj>Производительность имеет значение только тогда, когда ее не хватает. Вот наш проектик обслуживает примерно 7000-8000 подключений за сутки. Жалоб на производительность нету.
Я не знаю что там к чему подключается... но последнее серверное приложение которое мне доводилось писать лет пять назад обслуживало соединений на порядок больше и работало на каком-то там гигагерцовом xeon-е. Я далек от мысли что это является каким-то достижением.
kuj>Глобальное преимущество .NET и Java — удобство и скорость разработки. Покажи мне нормальные аналоги для Castle Windsor, MEF, ASP.NET MVC, nHibernate, Rhino Mocks, nServiceBus и т.д. и т.п и покажи мне средства для организации полноценного continuous integration процесса...
Я честно говоря ни одной из этих штук не пользовался... нет нужды. И надеюсь не появится в ближайшем будущем.
kuj>Delphi как была никчемной игрушкой для бедных ВУЗов и энтузиастов этого уродства под названием "delphi language", так ею и осталась.
Вот опустили... а я то тут в мелкой конторке маюсь с оборотом в USD $7M/год и клиентурой от Германии до Японии. И всё на Delphi.
Здравствуйте, Utruk, Вы писали:
U>Память ресурс не бесконечный. Бывает его занимают другие процессы. Бывает его просто мало. Бывает его требуется много. Бывают задачи в которых скорость критична.
U>Например одна из задач которых у меня есть должна обрабатывать картинки. Картинки формата от A5 до A3 с разрешением в 300..600 dpi и цветностью от B/W до True Color прилетают со частотой 2..3 страницы в секунду. За это время надо успеть её обработать (проверить не белая-ли, не загнутые ли углы, нет ли там баркода, не грязная ли ну и т.п.) и положить на хранение. Пока удается укладываться. Медленнее нельзя, при тех объемах которые есть даже 10% процентные тормоза становятся заметными, это уже деньги... Вот я и думаю, если у меня программа будет на C# а не на Delphi, я смогу сохранить скорость?
Ясное дело. Процессорное время на управление ресурсами в данном случае ничтожно мало в сравнении со временем на обработку собственно самих картинок.
Здравствуйте, Ночной Смотрящий, Вы писали:
U>>Тесты то запускали, али на стебе над % все остановилось? НС>У меня нет на машине компилятора Дельфи.
Придется значит вам поверить мне на слово что Delphi быстрее чем C#. Сами вы проверить не можете. Впрочем можете дальше продолжать петь алилуя сишарпу, вреда от этого никому не будет. У меня впрочем тоже создавалось скорострельности сего продукта в процессе прочтения того-же Рихтера. Но только в процессе прочтения, бумага она всё стерпит.
Здравствуйте, Utruk, Вы писали:
U>Здравствуйте, kuj, Вы писали:
kuj>>Здравствуйте, Utruk, Вы писали:
U>>>Тезис был "Delphi лучше C# потому что быстрее"... начиналось всё с "увеличения указателя и пары проверок", теперь уже "пооптимизируйте в других местах". В "других местах" оно даст эффект и с нативным приложением, тут заслуги сишарпа с дотнетом никакой.
kuj>>Производительность имеет значение только тогда, когда ее не хватает. Вот наш проектик обслуживает примерно 7000-8000 подключений за сутки. Жалоб на производительность нету.
U>Я не знаю что там к чему подключается... но последнее серверное приложение которое мне доводилось писать лет пять назад обслуживало соединений на порядок больше и работало на каком-то там гигагерцовом xeon-е. Я далек от мысли что это является каким-то достижением.
Что-то не верится.
kuj>>Глобальное преимущество .NET и Java — удобство и скорость разработки. Покажи мне нормальные аналоги для Castle Windsor, MEF, ASP.NET MVC, nHibernate, Rhino Mocks, nServiceBus и т.д. и т.п и покажи мне средства для организации полноценного continuous integration процесса...
U>Я честно говоря ни одной из этих штук не пользовался... нет нужды. И надеюсь не появится в ближайшем будущем.
Не стоит культивировать свое невежество.
kuj>>Delphi как была никчемной игрушкой для бедных ВУЗов и энтузиастов этого уродства под названием "delphi language", так ею и осталась. U>Вот опустили... а я то тут в мелкой конторке маюсь с оборотом в USD $7M/год и клиентурой от Германии до Японии.
Это премущество делфи?
Здравствуйте, Utruk, Вы писали:
U> Медленнее нельзя, при тех объемах которые есть даже 10% процентные тормоза становятся заметными, это уже деньги...
Деньги это время программиста, которое он будет тратить, пытаясь выловить очередную утечку памяти.
U>Здесь люди утверждают что сишарповский компилятор генерит код который выполняется быстрее чем дельфийский нативный. Простой пример с распределением миллиона объектов заставляет меня усомниться в этом.
Еще раз для тех, кто в танке: подобные синтетические тесты не имеют ровным счетом ничего общего с реальными задачами.
U>Страшно подумать что будет когда пример станет сложным и распределение каждого объекта будет сопровождаться распределением 30-ти метров памяти плюс
U>>>Тезис был "Delphi лучше C# потому что быстрее"... начиналось всё с "увеличения указателя и пары проверок", теперь уже "пооптимизируйте в других местах". В "других местах" оно даст эффект и с нативным приложением, тут заслуги сишарпа с дотнетом никакой.
kuj>>Производительность имеет значение только тогда, когда ее не хватает. Вот наш проектик обслуживает примерно 7000-8000 подключений за сутки. Жалоб на производительность нету.
U>Я не знаю что там к чему подключается... но последнее серверное приложение которое мне доводилось писать лет пять назад обслуживало соединений на порядок больше и работало на каком-то там гигагерцовом xeon-е. Я далек от мысли что это является каким-то достижением.
80 тыс соединений? 1 ггц xeon? и написано на Delphi? "Не верю!"
kuj>>Глобальное преимущество .NET и Java — удобство и скорость разработки. Покажи мне нормальные аналоги для Castle Windsor, MEF, ASP.NET MVC, nHibernate, Rhino Mocks, nServiceBus и т.д. и т.п и покажи мне средства для организации полноценного continuous integration процесса...
U>Я честно говоря ни одной из этих штук не пользовался... нет нужды. И надеюсь не появится в ближайшем будущем.
Все ясно. Ты хоть ВУЗ уже закончил?
kuj>>Delphi как была никчемной игрушкой для бедных ВУЗов и энтузиастов этого уродства под названием "delphi language", так ею и осталась.
U>Вот опустили... а я то тут в мелкой конторке маюсь с оборотом в USD $7M/год и клиентурой от Германии до Японии. И всё на Delphi.
