Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Embarcadero RAD Studio

Модерирует : ShIvADeSt

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323

Открыть новую тему     Написать ответ в эту тему

V1s1ter



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
         
Обсуждаем новые возможности и баги
 
Просьба писать про Embarcadero RAD Studio XE5, XE6, XE7, XE8, 10.x (Seattle, Berlin,Tokyo)
  По вопросам скачивания - Тема в Варезнике (lite-версии тут)
  Вопросы по неюникодным версиям Delphi — шестая бумага
  Бесплатные Компоненты и утилиты для Delphi/BCB/FreePascal/Lazarus
  Коммерческие компоненты и утилиты для Delphi/BCB
  Вопросы по компонентам для Delphi, C++ Builder разных версий
  Новые языковые возможности, начиная с Delphi 2005 по XE4 — здесь, и New!здесь еще
  Англоязычный официальный форум Embarcadero — здесь
  Embarcadero Quality Central, веб интерфейс — здесь, новый Quality Portal тут
  Программирование на Delphi — викиверситет
  Другие ресурсы
   Предыдущие бумаги
 
     Вопросы ..XE4       Вопросы ..XE3    Вопросы ..XE2      
  Вопросы ..2009-XE    Вопросы ..<2009 / ч.5    Вопросы ..<2009 / ч.4      
  Вопросы ..<2009 / ч.3    Вопросы ..Delphi 2 / ч.2    Вопросы ..Delphi  

  Выключение встроенного эксперта Castalia  для XE8 (иногда помогает при вылетах и тормозах)  
  Полезные плагины(эксперты)

Всего записей: 948 | Зарегистр. 06-02-2007 | Отправлено: 15:25 11-09-2013 | Исправлено: Komandor, 15:49 31-03-2024
SuPriTo



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

С такими граблями GC тебе и подавно не поможет и не его функция данную проблему решать.
На шарпе можно такие грабли тоже огрести не хило. Тут проблема библиотеки и не важно на чем она написана. Кривая библиотека она и в африке кривая. И мы не о так граблях рассуждаем.

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

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

Цитата:
Это просто твой иррациональный страх. Для дотнета есть куча performance counters которые покажут тебе всю статистику и одномоментные значения.  

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

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

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

Всего записей: 1475 | Зарегистр. 24-03-2009 | Отправлено: 13:55 05-01-2015 | Исправлено: SuPriTo, 13:57 05-01-2015
ZloyBrawler



Full Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору

Цитата:
в ручную у меня всяко лучше получится управлять памятью.

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

Всего записей: 514 | Зарегистр. 19-10-2010 | Отправлено: 14:08 05-01-2015
SuPriTo



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

Такие сообщения и на шарпе есть (точнее там нет, там приложение уходит тихо, чисто по английски). Я писал обмен данными между 2-мя приложениями через FileMapping. Насмотрелся на такие сообщения и просто на вылеты. Только при этом на Delphi не нужно было гадать остались ли ресурсы или нет, а вот на шарпе для таких задач пришлось выделять и чистить память в ручную. Сначала выделить кусок памяти, туда скопировать данный из автоматически очищаемой области памяти, а потом перенести в нужный мне буфер. И при этом пришлось глазеть на спокойные тихие вылеты приложения.
К слову сказать менеджер памяти в Delphi очень даже замечательный.

Всего записей: 1475 | Зарегистр. 24-03-2009 | Отправлено: 14:24 05-01-2015 | Исправлено: SuPriTo, 14:27 05-01-2015
antonpv



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Чуть-чуть поучаствую в вашей священной войне ;)
 

Цитата:
 И при этом пришлось глазеть на спокойные тихие вылеты приложения.  

Не умеете пользоваться исключениями в С#? НИКОГДА .net приложение не закрывается тихо, ТОЛЬКО если обернуть в try-except и не произвести обработку ошибок.
По рассуждениям товарищей, ругающих GC (и C#+.NET) в этой теме, думается мне, что они просто не имеют опыта и/или достаточных умений и навыков, а также познаний в предмете  обсуждения. Да, есть недостатки, но они есть у любых технологий и методов решения задач, и delphi, и c#, etc.
 
P.S.: А вот просветите меня, пожалуйста, если не лень, как дела сейчас обстоят с памятью в delphi? Мое развитие остановилось на XE2 :)
P.P.S: Реально делают миграцию C# -> C++ только в случаях, когда требуется очень критичное ко времени работы и затрат ЦП приложение, когда каждую миллисекунду берегут. Такое бывает не часто. В остальных случаях все отлично работает. И кстати, для любителей Паскаля, Н. Вирт в своих трудах начиная с Оберона ввел в язык автоматическую централизованную сборку мусора!

Всего записей: 65 | Зарегистр. 18-10-2012 | Отправлено: 14:41 05-01-2015 | Исправлено: antonpv, 14:51 05-01-2015
SuPriTo



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

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

Цитата:
ругающих GC

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

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

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

Всего записей: 1475 | Зарегистр. 24-03-2009 | Отправлено: 15:13 05-01-2015
Eternal_Shield

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
SuPriTo

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

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


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

Всего записей: 766 | Зарегистр. 18-05-2009 | Отправлено: 16:39 05-01-2015 | Исправлено: Eternal_Shield, 16:41 05-01-2015
ZloyBrawler



Full Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору

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

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

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

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

Всего записей: 514 | Зарегистр. 19-10-2010 | Отправлено: 16:41 05-01-2015
kaz_av

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
SuPriTo

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

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

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

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

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

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

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

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

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

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

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

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

Всего записей: 439 | Зарегистр. 15-02-2006 | Отправлено: 17:03 05-01-2015
antonpv



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

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

Всего записей: 65 | Зарегистр. 18-10-2012 | Отправлено: 17:11 05-01-2015
kaz_av

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Eternal_Shield

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

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

Всего записей: 439 | Зарегистр. 15-02-2006 | Отправлено: 17:14 05-01-2015
SuPriTo



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

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

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

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

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

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

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

Всего записей: 1475 | Зарегистр. 24-03-2009 | Отправлено: 17:24 05-01-2015 | Исправлено: SuPriTo, 17:36 05-01-2015
antonpv



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

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

Всего записей: 65 | Зарегистр. 18-10-2012 | Отправлено: 17:34 05-01-2015
SuPriTo



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

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

Цитата:
Спасибо, вопросов больше нет. 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 на шарпе - это уже почти натив. Правда им не удобно пользоваться. Код надо допиливать и дорабатывать.

Всего записей: 1475 | Зарегистр. 24-03-2009 | Отправлено: 17:54 05-01-2015
AlekXL



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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, который будет быстрее.

Всего записей: 792 | Зарегистр. 24-04-2008 | Отправлено: 19:10 05-01-2015 | Исправлено: AlekXL, 19:16 05-01-2015
SuPriTo



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

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

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

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

Всего записей: 1475 | Зарегистр. 24-03-2009 | Отправлено: 20:39 05-01-2015
kaz_av

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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.
 

Вот аналогичный на Delphi XE7:

Код:
 
program sb;
 
{$APPTYPE CONSOLE}
 
{$R *.res}
 
uses
  System.Classes,
  System.Contnrs,
  System.Diagnostics,
  system.SysUtils;
 
Type
 
 TTestClass = Class
  F0 : String;
  F1 : String;
  F2 : String;
  F3 : String;
  F4 : String;
  F5 : String;
  F6 : String;
  F7 : String;
  F8 : String;
  F9 : String;
  Constructor Create(AIndex : Integer);
 End;
 
{ TTestClass }
 
constructor TTestClass.Create(AIndex: Integer);
begin
 inherited create;
 
 F0 := 'StringBench0' + AIndex.ToString;
 F1 := 'StringBench1' + AIndex.ToString;
 F2 := 'StringBench2' + AIndex.ToString;
 F3 := 'StringBench3' + AIndex.ToString;
 F4 := 'StringBench4' + AIndex.ToString;
 F5 := 'StringBench5' + AIndex.ToString;
 F6 := 'StringBench6' + AIndex.ToString;
 F7 := 'StringBench7' + AIndex.ToString;
 F8 := 'StringBench8' + AIndex.ToString;
 F9 := 'StringBench9' + AIndex.ToString;
 
end;
 
Var
 
 sw      : TStopwatch;
 l       : TObjectList;
 k,i, lt : Integer;
 
begin
 
 lt := 0;
 for k := 1 to 100 do
  begin
 
   sw := TStopwatch.StartNew;
 
   l := TObjectList.Create;
   try
 
     for i := 1 to 100000 do
      l.Add(TTestClass.Create(i));
 
   finally
 
    l.Free;
 
   end;
 
   sw.Stop;
   inc(lt, sw.ElapsedMilliseconds);
 
   WriteLn(sw.ElapsedMilliseconds);
 
  end;
 
 WriteLn('-->', lt);
 
end.
 

Оксидженовый код собираем под JVM. Устанавливаем в ОC профиль максимальной производительности. Запускаем. Результат:
Java (Release. Open JDK x64): 6286
Delphi (Release. x64): 24214
Нужно заметить, что Open JDK далеко не самая быстрая JVM, но другой у меня нет. Дельфийский модуль запускался под Wine, поэтому мне интересно, какие результаты будут на чистой винде (впрочем, в тестовых операциях не задействуются системные функции, поэтому wine ни какого влияния оказывать не должен).
Архив с бинарниками тут.
CPU: AMD Phenom(tm) II X4 940 Processor. 3GHz.

Всего записей: 439 | Зарегистр. 15-02-2006 | Отправлено: 02:53 06-01-2015 | Исправлено: kaz_av, 02:56 06-01-2015
landy



Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

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

Всего записей: 576 | Зарегистр. 17-01-2003 | Отправлено: 16:19 06-01-2015
kaz_av

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
landy

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

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

Всего записей: 439 | Зарегистр. 15-02-2006 | Отправлено: 17:31 06-01-2015
SuPriTo



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

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

Всего записей: 1475 | Зарегистр. 24-03-2009 | Отправлено: 18:14 06-01-2015
Lena44



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

Всего записей: 282 | Зарегистр. 27-02-2007 | Отправлено: 18:43 06-01-2015
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323

Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Embarcadero RAD Studio


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru