» Вопросы по Embarcadero RAD Studio XE5-XE8,10.x(Seattle, Berl

Цитата:

НИКОГДА .net приложение не закрывается тихо

Выделите фиксированную часть памяти и заполните мусором. Если забьете стек и критически важные данные будет вам счастье.

Цитата:

ругающих GC

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

Цитата:

И кстати, для любителей Паскаля, Н. Вирт в своих трудах начиная с Оберона ввел в язык автоматическую централизованную сборку мусора!

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

SuPriTo

Цитата:

В GC у меня вечный вопрос, а почистилась ли память или нет?

а GC.Collect() не помогает получить ответ на этот вопрос? Не знаю какой ущерб по производительности наносит ентот вызов, но приложение в этом случае очень православно работало с моими задумками (работа с Delphi интерфейсами из DLL). Интересно, кто-нибудь ещё пользуется принудительной сборкой трэшака?

---

Что касается .net, да и вообще GC-based средств, то, имхо, каждое средство призвано решать своё множество задач и подобные решения никогда не были универсальными на все случаи жизни. Может быть, когда-нибудь, в отдалённом светлом будущем и станут ими, а на данный отрезок времени натив (С/С++ и, с некоторой натяжкой, Delphi) - единственное универсальное средство с помощью которого можно решить ЛЮБУЮ проблему с ЛЮБОЙ степенью эффективности ... проблема лишь в требуемом времени.

Имхо, одна из задач GC-based средств: Популяризация программирования среди народных масс и увеличить приток "рук" на рынок, и увеличить КПД рук намазав их сахарком. В итоге, популярные задачи решаются не так эффективно, но зато гораздо быстрее, чем на нативе, и проблем меньше.

Цитата:

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

Так вот это и есть бич современности ибо школоте некогда учить как правильно управлять памятью, создал форму over nine thousand контролово на ней, показал, скрыл и забыл в памяти... при том реально проще программировать при наличии GC, так как в хитросплетениях классов уже непонятно, что и когда должно освободиться, раньше чем надо рубанешь что-то, а это что-то еще где-то используется и если упаси бог нет проверок в коде на отсутствие объекта, то сразу ловим "access violation at address in module. Read of address", ну лень же везде писать проверки, надеемся на то что все будет штатно работать.
Уж лучше создать, поюзать и забыть, а там оно само как нить да утрясется. Конечно ресурсоемкие приложения с таким подходом не стоит программировать, но вот обычный софт корпоративного сегмента, где главбуху нужно посчитать почему не идет дебет с кредетом, да пожалуйста.

Добавлено:

Цитата:

Имхо, одна из задач GC-based средств: Популяризация программирования среди народных масс и увеличить приток "рук" на рынок, и увеличить КПД рук намазав их сахарком. В итоге, популярные задачи решаются не так эффективно, но зато гораздо быстрее, чем на нативе, и проблем меньше.

Всецело поддерживаю!

SuPriTo

Цитата:

И мы не о так граблях рассуждаем.

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


Цитата:

Эта паскудная грабля находится мин. за 15. возможностью отключения соответствующей библиотеки. Для меня такие проблемы решаемы.

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


Цитата:

Выделилось 300 мб памяти. Запускаю принудительную очистку памяти. Висим пару секунд и это только 300 мб. Чем больше, тем хреновей

Это ты на калькуляторе запускал? И вообще, show me your code!


Цитата:

Но чем больше узнаю, тем больше хочется от него избавиться, т. к. в ручную у меня всяко лучше получится управлять памятью.

Ну и зачем так себя мучить, пиши на дельфях. Вот мне шарп не нравится так я на нём и не пишу


Цитата:

К слову сказать менеджер памяти в Delphi очень даже замечательный.

Для однопоточки. В многопоточке он сосет.


Цитата:

Сборка мусора не подходит для написания критических ко времени работы и памяти приложений.

Попугли на предмет real-time gc и deterministic gc.

Цитата:

Выделите фиксированную часть памяти и заполните мусором. Если забьете стек и критически важные данные будет вам счастье.

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

Eternal_Shield

Цитата:

на данный отрезок времени натив (С/С++ и, с некоторой натяжкой, Delphi) - единственное универсальное средство с помощью которого можно решить ЛЮБУЮ проблему с ЛЮБОЙ степенью эффективности ... проблема лишь в требуемом времени.

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

Оффтоп
Тут конечно видео про сборщик на java
_https://www.lektorium.tv/lecture/14257
Но товарищ сказал, что они переписали сборщик для скоростной работы своих приложений.

Цитата:

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

Нет, не поделюсь. Я уже написал приложение. В процессе отладки у меня всякое выходило. Не туда указатель засунешь и начинается тихая веселуха, ничем не отличающаяся от натива. Если с таким не сталкивался в решение задач, то наверное и не понадобиться. А если интересно, то сам сможешь это исследовать.

Цитата:

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

Хочется конечно тоже вглянуть. Может ребята использовали TStringList для работы со строками, то понятно почему так все медленно работает. Дяденька на видео говорит, что типа java быстрее и для всех платформ существует. Но уточнив некоторые моменты, становится понятно, что нужно сильно постараться, чтобы такое написать.

Цитата:

Вот мне шарп не нравится так я на нём и не пишу

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

Цитата:

В процессе отладки у меня всякое выходило. Не туда указатель засунешь и начинается тихая веселуха, ничем не отличающаяся от натива.

Спасибо, вопросов больше нет. ROFL!

Цитата:

Для однопоточки. В многопоточке он сосет.

Что значит сосет? Все что в одном потоке выделил, в нем и прикрой. И будет счастье.

Цитата:

Спасибо, вопросов больше нет. ROFL!

Код весь тебе не дам, но направление для поисков.
И все это надо оформить в процедуру с параметром unsafe. Флаг unsafe - это уже почти нативное приложение.
IntPtr _Buffer = IntPtr.Zero;//Где указатель _Buffer на выделенный через CreateFileMapping и MapViewOfFile.
IntPtr ptr = Marshal.AllocHGlobal(Size); //Выделяем память и туда надо записать что-то
try {
Marshal.Copy(Data, 0, ptr, Size); //Data - это какие-нибудь данные
IntPtr temp = @_Buffer;
Win32.memcpy(temp, Data, Size); //Копируем данные
}
finally {
Marshal.FreeHGlobal(ptr); //Удаляем память
}
Если загадишь стек или какие-то важные данные будет различные неожиданные спецэффекты. Но они везде будут. Флаг unsafe на шарпе - это уже почти натив. Правда им не удобно пользоваться. Код надо допиливать и дорабатывать.

kaz_av

Цитата:

Только в твоей теории

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

Операция выделения памяти для GC это изменение указателя и только, а это очень дешевая операция даже по сравнению с менеджерами памяти основанными на пулах.

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


Цитата:

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

какой работы? выделения памяти? Для этого не особо нужна статистика

Цитата:

У GC нет проблемы с циклическими ссылками

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


Цитата:

и фрагментацией памяти.

а сколько стоит дефрагментация? Потом, проблема фрагментации несколько надуманна.

Цитата:

GC более cache friendly, чем подсчет ссылок. Это если говорить о теории.

Я об этом не слышал что-то, но даже если так, то не намного.


Цитата:

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

Сравнивая GC и подсчет ссылок, можно и нужно взять пример iOS и Android: это факт, что на iOS программы отзывчивее и быстрее. Вот тебе и реальный результат[

Цитата:

Так ты не думай, ты проверь! Неверные предпосылки, они, как известно, ведут к неверным выводам. Ты в курсе, что GC может работать параллельно основным кодовым потокам и практически исключить появление пауз?

Про паузы -- чистое вранье.
Как тебе писали:"Конечно он может, но от пауз не избавляет "


Цитата:

Вообще говоря, на хороший код GC влияния не оказывает чуть менее чем совсем

Разве что на идеальный код. Не просто хороший. Но он никому практически не по карману.


Цитата:

Конкурентный избавляет размазывая время на просмотр графа.

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

Цитата:

У двоечников считающих GC серебряной пулей.

Так других пуль там нету! Нету ручного контроля выделения памяти. Нету выбора! В Delphi я что-то контролирую вручную, что-то делегирую подсчету ссылок.


Цитата:

А в курсе, что подсчет ссылок в дельфях, сделанный на основе вызова виртуальных (двойнойрукалица) методов адово замедляет работу приложения?

ЧТО? это вызов косвенный адово замедляет? Во времена, когда в тренде Dependency Injections и интерфейсы(в которых все вызовы косвенные)?
Или ты про передачу параметра? Так сделай его константным, тогда не будет AddRef/Release..


Цитата:

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

Это редкая проблема. И притом нужно, чтобы буфер был аллоцирован в стеке -- это практика нетривиальная в Delphi. Тем более, культура Delphi программирования не поощряет использование библиотек без исходников.
А если есть исходники, то проблему найти достаточно легко, если она уже проявилась.

Цитата:

Вот ты воюешь с GC, а воевать не нужно, нужно узнать побольше.

В основном про внутренне устройство M$ GC мало что известно. Вот в яве, там да, по GC немало инфы.


Цитата:

неисповедимы пути господни.... "access violation at address in module. Read of address"...

и что? Это ни разу не проблема!
Проблема, когда тихо портится память, особенно внутренние структуры кучи.
В дельфи любая явная проблема - это уже не проблема, все поправимо, если есть голова и способность к анализу. Ты всегда что-то можешь предпринять..

А проблемы с памятью, задержками в managed среде GC -- проблема неявная. Это худший вид проблем.


Цитата:

Для однопоточки. В многопоточке он сосет

есть scaleMM . В разы быстрее дефолта именно в многопоточке. А главное, есть выбор!


Цитата:

Попугли на предмет real-time gc и deterministic gc

ты всех своих оппонентов посылаешь в гугль? Не от ума и нет от совести делаешь это.

Когда тебе выгодно, не гнушаешься теориями, но вот практика GC показывает обратное.
Насколько известно, нету в природе высогонагруженных и сложных managed приложений работающих по стандарту реального времени. Это нетривиальная задача даже для истинно нативных решений.





Eternal_Shield

Цитата:

GC.Collect() не помогает получить ответ на этот вопрос? Не знаю какой ущерб по производительности наносит ентот вызов, но приложение в этом случае очень православно работало с моими задумками (работа с Delphi интерфейсами из DLL). Интересно, кто-нибудь ещё пользуется принудительной сборкой трэшака?

при сборке происходит продвижение в поколениях, так что вызов GC.Collect() не шутка.
.




Добавлено:
kaz_av


Цитата:

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

боже, какая клюква!.. Работа со строками- один из коньков Delphi.

Напиши любой нагруженный код со строками на жабе или доднете, и я напишу код Delphi, который будет быстрее.

Цитата:

А проблемы с памятью, задержками в managed среде GC -- проблема неявная. Это худший вид проблем.

Вот это одна из проблем. Вторая - WCF.
Это основные сложности.

Цитата:

при сборке происходит продвижение в поколениях, так что вызов GC.Collect() не шутка.

3-е поколение - очень интересное поколение. Может автоматически не чиститься.

SuPriTo

Цитата:

Что значит сосет? Все что в одном потоке выделил, в нем и прикрой. И будет счастье.

Сосет это значит тупо падает производительность, и чем больше потоков обращаются к менеджеру тем сильнее падает.

AlekXL

Цитата:

так считают многие программисты

Цитата:

И выделение памяти там тоже дешевая операция.
Думаю, более дешевая, чем у GC. Ведь у GC тоже свой пул.

Считают, думаю... Аргументы так аргументы.


Цитата:

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

У менеджеров конечно нет, это геморой программиста. Только с GC его нет.


Цитата:

а сколько стоит дефрагментация? Потом, проблема фрагментации несколько надуманна.

Сколько бы она ни стоила, она лучше EOutOfMemory.


Цитата:

Я об этом не слышал что-то, но даже если так, то не намного.

Это прекрасно. Не слышал, но уверен, что не на много.


Цитата:

Сравнивая GC и подсчет ссылок, можно и нужно взять пример iOS и Android: это факт, что на iOS программы отзывчивее и быстрее. Вот тебе и реальный результат

У меня нет айфона, но ты вот мне ответь, почему на своём ведроиде я ни каких тормозов и проблем с отзывчивостью не наблюдаю? Ну т.е. если запустить аппу собранную с обезьяной они конечно сразу обнаруживаются, но дело тут-то точно не в GC


Цитата:

Про паузы -- чистое вранье.
Как тебе писали:"Конечно он может, но от пауз не избавляет "

К Рихтеру и гуглу доверия как-то больше, уж извини.


Цитата:

Разве что на идеальный код. Не просто хороший. Но он никому практически не по карману.

Ок. Пусть будет идеальный. Теперь скажи, а кому по карману идеальный код в нативе? Прикол в том, что специалисты, что в одном, что в другом стоят дорого. А вот середнячки с нативом в руках, что обезьяны с гранатой.


Цитата:

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

Работает-работает, просто увеличивается время на просмотр графа. А полный останов требуется только для уплотнения, которое не явлется частой операцией.


Цитата:

Так других пуль там нету! Нету ручного контроля выделения памяти. Нету выбора! В Delphi я что-то контролирую вручную, что-то делегирую подсчету ссылок.

Да я не о том. Просто не нужно думать, что при использовании GC можно голову выключать. Я уже писал, что GC это инструмент и им нужно уметь пользоваться, а не просто: "память безгранична, ООП головного мозга, щас спою".


Цитата:

ЧТО? это вызов косвенный адово замедляет? Во времена, когда в тренде Dependency Injections и интерфейсы(в которых все вызовы косвенные)?

Читай.


Цитата:

Это редкая проблема. И притом нужно, чтобы буфер был аллоцирован в стеке -- это практика нетривиальная в Delphi.

Это статические-то массивы на стеке нетривиальная практика??? Куда уж тривиальнее...


Цитата:

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

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


Цитата:

В основном про внутренне устройство M$ GC мало что известно. Вот в яве, там да, по GC немало инфы.

У Рихтера есть книжка посвященная GC. Есть статьи с детальным разбором. Ищущий да обрящет.


Цитата:

есть scaleMM . В разы быстрее дефолта именно в многопоточке. А главное, есть выбор!

SMM из стадии эксперимента все никак не выйдет. А его наличие никак не отменяет отстойности стандартного менеджера в многопоточке.


Цитата:

ты всех своих оппонентов посылаешь в гугль? Не от ума и нет от совести делаешь это.

А ты бы хотел, чтоб я я сюда постил многостраничные тексты? Пару слов в гугл вбить очень сложно? И желательно бы делать это до смелых заявлений о неподходящих технологиях.


Цитата:

Насколько известно, нету в природе высогонагруженных и сложных managed приложений работающих по стандарту реального времени.

Высокочастотный трейдинг достаточно серьезное применение? Вот например, написан на жабе.


Цитата:

боже, какая клюква!.. Работа со строками- один из коньков Delphi.
Напиши любой нагруженный код со строками на жабе или доднете, и я напишу код Delphi, который будет быстрее.

Вот тебе простой пример на Oxygen:

Код:
namespace consoleapplication1;

interface

uses
java.util, java.lang;

type
ConsoleApp = class
public
class method Main(args: array of String);
end;

Type

TTestClass = Class

F0 : String;
F1 : String;
F2 : String;
F3 : String;
F4 : String;
F5 : String;
F6 : String;
F7 : String;
F8 : String;
F9 : String;

Constructor (AIndex : Integer); Virtual;

End;

implementation

//
Constructor TTestClass(AIndex : Integer);
Begin

inherited constructor;

F0 := new StringBuilder('StringBench0').append(AIndex).toString;
F1 := new StringBuilder('StringBench1').append(AIndex).toString;
F2 := new StringBuilder('StringBench2').append(AIndex).toString;
F3 := new StringBuilder('StringBench3').append(AIndex).toString;
F4 := new StringBuilder('StringBench4').append(AIndex).toString;
F5 := new StringBuilder('StringBench5').append(AIndex).toString;
F6 := new StringBuilder('StringBench6').append(AIndex).toString;
F7 := new StringBuilder('StringBench7').append(AIndex).toString;
F8 := new StringBuilder('StringBench8').append(AIndex).toString;
F9 := new StringBuilder('StringBench9').append(AIndex).toString;

End;
//

class method ConsoleApp.Main(args: array of String);
begin

var k : Integer;
var lt := 0;
for k := 1 to 100 do
begin

var time := System.currentTimeMillis();
var i : Integer;
var l := new ArrayList;

for i := 1 to 100000 do
l.add(new TTestClass(i));

l := nil;

var t := System.currentTimeMillis() - time;
inc(lt, t);

System.out.println(t);

end;

System.out.println('-->' + lt.toString);

end;

end.

Цитата:

Высокочастотный трейдинг достаточно серьезное применение? Вот например, написан на жабе.

Безотносительно всего остального - некоторые (очень многие) высокочастотным трейдингом считают 10 сделок в минуту. Так что без цифр пример не считается.

landy

Цитата:

Так что без цифр пример не считается.

Я бы им занимался, были бы и цифры

Цитата:

Высокочастотный трейдинг достаточно серьезное применение?

Высокочастотный трейдинг - это трейдинг, в котором существует зависимость результата от скорости выставления заявки. Если такой зависимости нет, то это обычный робо-трейдинг.
Тут не только важна скорость обработки данных, важна скорость выставления заявок, прямой доступ к бирже, близость к бирже, инфраструктура и т. д. Очень много условий. Так ведь пишут java и на шарпе. Но сколько усилий для этого надо, чтобы написать качественный и быстрый код. И в плане трудоемкости, нет разницы, что на Java, что на шарпе, что на с++, что на делфи. На java или шарпе написать программу работающую с реал-тайм данными написать сложнее, чем на нативе (ИМХО). Лично мне сложнее написать именно из-за сборщика мусора.

Я уверена, что участники этой ветки идут на поводу какой-то бесполезной дискуссии. Эту бесполезность провоцируют такие участники как например kaz_av.
В своё время был задан вопрос, а что вы сделали на fmx? Ответила. Все работает отлично в сфере фаст фуд. Заказчик доволен. Все четко и отлично. А вот kaz_av сообщает нам все это чушь. Очень странный товарищ.
По моему мнению для корпаративных задач - fmx хорошее решение. Правда я решала свою задачу не на паскале а на с++.
Я рассматриваю fmx как и RAD в целом, только как инструмент решения корпаративных задач, а не массового использования в маркете. Это логично и удобно.
А такие товарищи как
kaz_av это пустота дискуссии и пустая трата времени.

Lena44

Цитата:

kaz_av это пустота дискуссии и пустая трата времени.

Мне лично дискуссия понравилась и оказалась полезной.

SuPriTo

Цитата:

Если такой зависимости нет, то это обычный робо-трейдинг.

На сайте же прямо написано - high-frequency. Контора работающая в этой области и продающая продукт, в курсе наверное о чем говорит.

Lena44

Цитата:

Эту бесполезность провоцируют такие участники как например kaz_av.

Я провоцирую? Может стоит почитать с чего разговор начался.

Цитата:

Я рассматриваю fmx как и RAD в целом, только как инструмент решения корпаративных задач, а не массового использования в маркете.

А рекламные компоненты абракадабра тоже для корпоративщиков в поставку втулила?

И таки да, твой запускатель видеоплейера несомненно достойный пример использования платформы. Иди с миром.

Цитата:

На сайте же прямо написано - high-frequency. Контора работающая в этой области и продающая продукт, в курсе наверное о чем говорит.

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

Добавлено:

Цитата:

По моему мнению для корпаративных задач - fmx хорошее решение. Правда я решала свою задачу не на паскале а на с++.

Лена, в данном случае именно ты сбиваешь планку дискуссии

landy

Цитата:

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

По той ссылке и цифры находятся.

kaz_av

Цитата:

Результат:
Java (Release. Open JDK x64): 6286
Delphi (Release. x64): 24214

Сколько байт занимает один символ в Java?

data man

Цитата:

Сколько байт занимает один символ в Java?

2 байта, как и в Delphi и в C#.

В D тоже есть GC.
Ради интереса написал:
[more=Код]
Код:
import std.stdio, std.array, std.conv, std.datetime;
// compile with "-O -inline -release -noboundscheck" options

class TTestClass
{
string F0;
string F1;
string F2;
string F3;
string F4;
string F5;
string F6;
string F7;
string F8;
string F9;

this(int AIndex)
{
F0 = "StringBench0" ~ to!string(AIndex);
F1 = "StringBench1" ~ to!string(AIndex);
F2 = "StringBench2" ~ to!string(AIndex);
F3 = "StringBench3" ~ to!string(AIndex);
F4 = "StringBench4" ~ to!string(AIndex);
F5 = "StringBench5" ~ to!string(AIndex);
F6 = "StringBench6" ~ to!string(AIndex);
F7 = "StringBench7" ~ to!string(AIndex);
F8 = "StringBench8" ~ to!string(AIndex);
F9 = "StringBench9" ~ to!string(AIndex);
}
}

void main()
{
StopWatch SW;
uint lt;
import core.memory;
// GC.disable();

foreach(int k; 0..100)
{
SW.start;
auto l = appender!(TTestClass[]);
try
{
foreach(int i; 0..100000)
{
l ~= new TTestClass(i);
}
}
finally
{
l.clear;
}
SW.stop;
lt += SW.peek().msecs;
SW.reset;
}
writeln("-->", lt);

// GC.enable();
}

data man

Код:
kazalex@kazalex-pc:~/Downloads$ wine BenchAllocateGCDisable.exe
-->36569

kazalex@kazalex-pc:~/Downloads$ wine BenchAllocateGCEnable.exe
-->62070

kaz_av

Цитата:

BenchAllocateGCEnable.exe
-->62070

Результат немного удручает, да.

Цитата:

У тебя там в обоих циклах на одну итерацию больше.

Нет, правая граница не считается.

Цитата:

И разве в D нет аналога стрингБилдера

Есть, всё тот же appender.
На самом деле я немного схитрил: тип string хранит строки в UTF-8. Для чистоты эксперимента нужно заменить на wstring.
Вообще, после D и Delphi и С++ кажутся какими-то...недоязыками, извините.


Добавлено:
Всё-всё, ухожу-ухожу.

data man

Цитата:

Нет, правая граница не считается.

Вот всё у вас ни как у людей

Цитата:

Сколько бы она ни стоила, она лучше EOutOfMemory.

Только вот момент, когда заканчивается память у managed приложения наступает много раньше, чем у натива. Из-за GC. Покажи мне пример, когда, проблема фрагментации стала для натива стала критичной.

Цитата:

Это прекрасно. Не слышал, но уверен, что не на много.

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


Цитата:

У менеджеров конечно нет, это геморой программиста. Только с GC его нет.

но есть другой?
Цитата:

при использовании GC можно голову выключать. Я уже писал, что GC это инструмент и им нужно уметь пользоваться, а не просто: "память безгранична, ООП головного мозга, щас спою".

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

Цитата:

Это статические-то массивы на стеке нетривиальная практика??? Куда уж тривиальнее...

я лично такое использую редко. И если проблема проявится, то по стеку вызовов это место будет одним из первых для анализа и проверки.

Притом я сам всегда делаю буфер, как ты говоришь: "на 1-2 байта" больше, чем ожидаю получить:занижаю декларированный для АПИ размер. Это мой личный опыт.


Цитата:

Работает-работает, просто увеличивается время на просмотр графа.

как его можно до конца проанализировать, когда он постоянно меняется? И даже если можно, сколько процессорного времени будет это занимать?


Цитата:

У меня нет айфона, но ты вот мне ответь, почему на своём ведроиде я ни каких тормозов и проблем с отзывчивостью не наблюдаю?

это что за аргумент? Проблемы с отзывчивостью андроида общеизвестны.
Их может не быть на топовых устройствах, конечно, с большим объемом оперативной памяти. Сколько в твоем?
Но если взять взять android телефон по тех характеристикам равный iPhone(<=1Gb RAM), какой будет ситуация?


Цитата:

Ну т.е. если запустить аппу собранную с обезьяной они конечно сразу обнаруживаются, но дело тут-то точно не в GC

это проблема FMX, никто не говорит, что он хорош.


Цитата:

У Рихтера есть книжка посвященная GC. Есть статьи с детальным разбором. Ищущий да обрящет.

это опять отсылка в гугль?

Цитата:

SMM из стадии эксперимента все никак не выйдет.

пустая отмазка. Чем он плох?

Цитата:

А его наличие никак не отменяет отстойности стандартного менеджера в многопоточке.

не отменяет. Ну и что? Менеджер памяти для Delphi - вагон. И их можно кастомизировать средствами самого языка, в отличие от GC;они много проще устроены,так что это посильная задача даже для одиночки.
Мы-то знаем, что некоторые джависты в своей борьбе с ущербным инструментом пишут свои GC, и вот это -- хардкор.


Цитата:

Теперь скажи, а кому по карману идеальный код в нативе?

никому почти. Но он и не нужен. Даже средний код нативный -- очень быстр.

Цитата:

А вот середнячки с нативом в руках, что обезьяны с гранатой.

ложь. Думаешь Windows писали одни асы? А Delphi среду? А любой движок БД?

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


Цитата:

А ты бы хотел, чтоб я я сюда постил многостраничные тексты? Пару слов в гугл вбить очень сложно?

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

Цитата:

Цитата:
ЧТО? это вызов косвенный адово замедляет? Во времена, когда в тренде Dependency Injections и интерфейсы(в которых все вызовы косвенные)?

Читай.

Это 5 процентов овехеда -- чудовищное замедление? Что за ерунда? А сколько жрет GC, пусть даже работая в фоне?
Потом, мы не знаем кейса. Может, он в тугом цикле перекидывает ссылки на объекты как параметры, без const или var модификатора. Подсчет ссылок -- это ведь тоже не серебряная пуля. Но справиться с подсчетом все же проще , чем с GC.


Цитата:

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

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

Цитата:

Высокочастотный трейдинг достаточно серьезное применение? Вот например, написан на жабе

тут чел уже давал ссылку
https://www.lektorium.tv/lecture/14257
там умудренный джавист два часа распинался, как борясь с языком и парадигмой GC(по сути, они реализовывали свои кастомные неуправляемые кучи, чтобы избежать GC), а также ломая парадигмы не только ООП, но даже и просто структурного программирования, -- словом, пускаясь во все тяжкие, они добивались скорости.
Да уж, толк в извращениях они знают.

И да,объем знаний, который при этом был задействован, столь велик, что мне рассудилось, что было проще нанять команду "средних" нативщиков, которые будут писать неидеальный но все же очень быстрый (ибо натив и без GC) код, ну и одного аса, который будет за ними подчищать утечки и прочие скорбные дела натива.

AlekXL

Цитата:

Только вот момент, когда заканчивается память у managed приложения наступает много раньше, чем у натива. Из-за GC.

Когда у GC заканчивается память, он уплотняет кучу. Когда у нативного менеджера память фрагментировалась - game over.

Цитата:

Покажи мне пример, когда, проблема фрагментации стала для натива стала критичной.

Гуглиться на раз.

Цитата:

Это ты не дал никакий ни теоретических, ни практических обоснований для своего утверждения.

Какие обоснования тебе нужны? Что работает быстрее: последовательный просмотр памяти или прыжки по разным участкам? Так вот первый сценарий это GC, второй - подсчет ссылок.

Цитата:

но есть другой?

У программиста нет. Есть определенные требования к среде исполнения.

Цитата:

Так то!

Так я с самого начала об этом твержу. С чем ты спорил-то?

Цитата:

я лично такое использую редко. И если проблема проявится, то по стеку вызовов это место будет одним из первых для анализа и проверки.

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

Цитата:

Притом я сам всегда делаю буфер, как ты говоришь: "на 1-2 байта" больше, чем ожидаю получить:занижаю декларированный для АПИ размер. Это мой личный опыт.

А чего не на 4 или 8?

Цитата:

как его можно до конца проанализировать, когда он постоянно меняется?

Прочитай уже, как работает concurent GC.

Цитата:

И даже если можно, сколько процессорного времени будет это занимать?

Я тебе предлагал уже самому посмотреть на счетчики любого дотнетовского приложения. Всё от ситуации зависит, когда я мониторил одну софтину там GC кушал сотые доли процента.

Цитата:

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

Сравнивать iOS и Android, для поисков истины в споре ARC vs. GC, вообще глупо т.к. iOS является оптимизированным решением для железа единственного вендора, а Android универсальная ОС работающая на диком зоопарке разношерстного говна. У меня аппарат далеко не флагман, скорее середнячек. Памяти там 2Gb, но свободной почти гигабайт. Я тебе больше скажу, на моей старой нокии, работающей на S60, была установлена Java ME и несколько игрушек для неё, которые работали без каких либо проблем. Памяти на аппарате было всего-то 4Mb.

Цитата:

это опять отсылка в гугль?

Я не пойму, ты от меня ссылок ждешь, или перепоста книги и статей? Ну возьми да вбей ".net gc richter", и получишь желаемое.

Цитата:

пустая отмазка. Чем он плох?

Кроме того, что не пригоден для использования в продакшене? Ничем.

Цитата:

И их можно кастомизировать средствами самого языка, в отличие от GC;они много проще устроены,так что это посильная задача даже для одиночки.

Ты уже начал свой писать, чтоб обогнать жабий GC на строках?

Цитата:

Даже средний код нативный -- очень быстр

Да, он очень быстро падает.

Цитата:

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

Нет, просто насмотрелся.

Цитата:

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

Я по возможности даю конкретные ссылки, а когда предлагаю погуглить то контекста ясно что искать (пример выше был дан). А перечитывать статьи и кратко их тебе пересказывать мне, увы, не интересно. Если ты берешься спорить, а теории не хватает, то это не моя проблема.

Цитата:

Это 5 процентов овехеда -- чудовищное замедление?

Из ничего - не то слово.

Цитата:

А сколько жрет GC, пусть даже работая в фоне?

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

Цитата:

Потом, мы не знаем кейса.

Это не обязательно. Достаточно знать, как в дельфях финалятся управляемые типы, а объекты в мобильном компиляторе, о котором речь, как раз управляемые. Досаточно декларировать в процедуре/функции/методе переменную управляемого типа, и ты попадаешь на неявный вызов финализатора. Ну и если такой метод часто вызывать, то просадка может быть весьма ощутимой.

Цитата:

GC от них не гарантирует.

Их позволяет избежать управляемый safe code.

Цитата:

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

А он там не рассказал, чего они не взяли нативные плюсы?

Почему GC от C# убивает TrayIcon? Дело в том что в программе я не делал Visible = false. В логе видел Visible = true, но у пользователя пропадала иконка и он не мог зайти в программу.

Добавлено:

Цитата:

Да, он очень быстро падает.

У дровосеков одной и той же квалификации - реже падает. Там гораздо больше экзепшенов прописано - труднее заблудиться в вариациях на тему.

Добавлено:
Разницы между подсчётом ссылок и счётчиком особой не вижу. Мне больше нравится самостоятельно высвобождать память или губить ссылку, заранее зная что объект останется.

xpin2013

Цитата:

Почему GC от C# убивает TrayIcon? Дело в том что в программе я не делал Visible = false. В логе видел Visible = true, но у пользователя пропадала иконка и он не мог зайти в программу.

GC не может убить объект на который есть ссылки. Может у твоего юзера винда скрыла иконку, или твоя софтина не умеет восстанавливать иконку после падения эксплорера?


Цитата:

труднее заблудиться в вариациях на тему.

AV указывающий на мусор мало чем тебе поможет, а это очень распространенная ситуация.


Цитата:

Разницы между подсчётом ссылок и счётчиком особой не вижу.

В смысле, между ARC и GC?


Цитата:

Мне больше нравится самостоятельно высвобождать память или губить ссылку, заранее зная что объект останется.

И мне больше нравится натив. Я пишу на дельфях уже 16 лет, а до этого два года писал на TurboPascal + Assembler. Но я не слепой фанатик, и не собираюсь отрицать плюсы GC и минусы натива, равно как и замалчивать проблемы конкретно дельфей.