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

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в 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 324 325 326 327

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

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
landy



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

Цитата:
Взгляни на SQL parser for VCL

Вдогонку - вот еще один парсер структуры БД: Database Comparer VCL v 6.1 for Delphi, C++Builder

Всего записей: 576 | Зарегистр. 17-01-2003 | Отправлено: 22:59 02-01-2015
mrUlugbek



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

Цитата:
Привет!
 
Как и с помощью чего можно реализовать такую фичу аля 1С8 лукап список выбора
 
http://uploads.ru/A2Sia.png
 
При наборе символов в поле ввода, подключенному к справочнику по первым нескольким символам отображается лукап список с совпадающими элементами, при выборе из которого в поле копируется нужный элемент.  
Спасибо.

 
 
Посмотри у Ehlib есть такой функционал не эта случайно  
 
Ссылка
 
 

Всего записей: 888 | Зарегистр. 04-04-2011 | Отправлено: 11:00 03-01-2015
SolidSnakeRU

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
http://www.3dnews.ru/907498/?feed
Судя по всему, сделано на ФМ.

Всего записей: 248 | Зарегистр. 27-08-2008 | Отправлено: 13:01 03-01-2015 | Исправлено: SolidSnakeRU, 13:01 03-01-2015
landy



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

Цитата:
Судя по всему, сделано на ФМ.

Эм, а что именно наводит тебя на такую мысль?

Всего записей: 576 | Зарегистр. 17-01-2003 | Отправлено: 14:17 03-01-2015
SolidSnakeRU

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Название, вид контролов и отзывы.
"Жрет память", "вылетает", "не работает".

Всего записей: 248 | Зарегистр. 27-08-2008 | Отправлено: 16:12 03-01-2015
kaz_av

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
SolidSnakeRU
Не на обезьяне оно. В ресурсы загляни. При таком количестве закачек оценка обезьяньего софта находилась бы на уровне одного балла.

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



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

Цитата:
Судя по всему, сделано на ФМ.

А мы всё надеемся и ждем чуда: что на FMX все же можно писать элегантный софт..  
А может, ну его? Весь мир движется к "жрущему" и тормозному софту под флагами .NET и прочих скриптовых GC поделий. Давайте и мы будем говнокодить, только на Delphi/FMX. Ведь сложное приложение на далвике, и такое же приложение на FMX -- тормозить будет одинаково жестко, не так ли?
Это только на простых у жабы преимущество.
 
---
 
а кто пользовался "препроцессором" http://sourceforge.net/projects/dpp32/?source=typ_redirect Delphi?
И есть ли подобные фишки еще?

Всего записей: 792 | Зарегистр. 24-04-2008 | Отправлено: 21:31 04-01-2015 | Исправлено: AlekXL, 21:41 04-01-2015
kaz_av

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

Цитата:
Весь мир движется к "жрущему" и тормозному софту под флагами .NET и прочих скриптовых GC поделий.

Все как раз наоборот У ведроида ART уже в новых версиях активирован по дефолту, у МС его аналог (или, если угодно, аналог ngen, в общем тот самый AOT вместо JIT) работает на стороне магазина приложений. Теперь байт-код служит лишь временным представлением программного кода от момента сборки до момента установки приложения, а дальше работает натив (индустрия таки вернулась к изначальной идее ). Теперь ведроидный SDK-софт мало чем будет отличаться в плане производительности от NDK-софта, и, возможно, необходимость в последнем со временем вообще отпадет.
 

Цитата:
Давайте и мы будем говнокодить, только на Delphi/FMX

Ждем саксесс стори от тебя.

Всего записей: 450 | Зарегистр. 15-02-2006 | Отправлено: 22:15 04-01-2015
AlekXL



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

Цитата:
, а дальше работает натив (индустрия таки вернулась к изначальной идее ).  

 
нет, не вернулась. Как ты не поймешь, дело вовсе не в интерпретации и джиттерах, а в ручном управлении памятью. А значит, нет возможности создавать специализированные высокоэффективные структуры данных(контейнеры) для критических по отн. к памяти  алгоритмических задач. Отсюда все растет, я считаю.  
 
Ты не знаешь, когда будет освобожден неиспользуемый буфер.  Но когда это произойдет, то будет тормоз на весь пул потоков, без изъятий , то есть либо заикание интерфейса, либо что похуже.  
 
Я видел сложный и объемный проект на шарпе, предназначенный для автотрейдинга на форекс-подобных биржах. Девелоперы(по уровню знаний программирования - любители, неспецы) жаловались на микрозадержки порядка 30мс, которые были для них критичны. Так вот, они не торговались, когда нужно было что-то с этим сделать... А сделать что-то весьма нелегко -- либо рефакторить всё, все явные и неявные выделения памяти, боксинг и т.д в цикле обработки и соседних нитях . Либо писать демона в отдельном контексте, и желательно, не на GC-платформе.
--
..Если бы в доднете была бы хотя бы возможность вручную аллоцировать память под структурный тип, или буфер, тогда еще ладно, но такой возможности нет. Да и сама идея достижимости, в отличие, скажем,  от подсчета ссылок, порочна.
 
Добавлено:
Добавь сюда практически горизонтально-асимптотический тренд развития железа, по сравнению с как минимум линейным прогрессом алгоритмических решений, и увидишь не упадок парадигмы NDK, а "Возвращение Короля".  
Может вернуться то время, когда нас удивляли одиночки, умещавшие шедевры в 48/128 килобайт "Cпекки" или "Коммодора", только вместо одиночек будут корпорации.

Всего записей: 792 | Зарегистр. 24-04-2008 | Отправлено: 22:56 04-01-2015 | Исправлено: AlekXL, 23:17 04-01-2015
Alexey_Gawrilow



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

Цитата:
Теперь байт-код служит лишь временным представлением программного кода от момента сборки до момента установки приложения, а дальше работает натив (индустрия таки вернулась к изначальной идее  ).

 
Ну как вот не вспомнить Михаеля Франца с его Juice.
Шикарная вещь.
Единственный недостаток - "фатальный недостаток"
Ну или так
 
 
Добавлено:
AlekXL

Цитата:
препроцессором


Цитата:
И есть ли подобные фишки еще?

DLangExtensions от Andreas Hausladen была крута. Имеется ввиду именно инженерное решение - Andreas безусловно крут.
 
http://www.devsuperpage.com/search/Articles.asp?ArtID=1143196
 
мертвое сейчас.

Всего записей: 640 | Зарегистр. 08-09-2003 | Отправлено: 23:14 04-01-2015
AlekXL



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
друзья, а здесь есть кто-нибудь, кто бескорыстно коммиттит в развитие Delphi/FPC?

Всего записей: 792 | Зарегистр. 24-04-2008 | Отправлено: 23:29 04-01-2015
kaz_av

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

Цитата:
нет, не вернулась.

В плане работы с байт-кодом - 100% вернулась.
 

Цитата:
Отсюда все растет, я считаю

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

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

У самой платформы скорее всего есть, на уровне шарпа возможно нет. Например FPC умеет компилировать под JVM - платформу с управляемой памятью и GC - и при этом работают низкоуровневые трюки с указателями и управлением памятью.
 

Цитата:
Да и сама идея достижимости, в отличие, скажем,  от подсчета ссылок, порочна.

Идея как раз красивая. Подсчет ссылок более проблематичен, а в реализации дельфей для объектов вообще убог - слабые ссылки в глобальном списке это - рукалицо.
 
Добавлено:
AlekXL

Цитата:
друзья, а здесь есть кто-нибудь, кто бескорыстно коммиттит в развитие Delphi/FPC?  

А в Delphi можно коммитить?

Всего записей: 450 | Зарегистр. 15-02-2006 | Отправлено: 23:43 04-01-2015
AlekXL



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

Цитата:
Об этом нужно говорить с цифрами в руках, т.е. делать многократное профилирование и выяснение действительно узких мест. Может статься, что GC окажется не при делах. Ну и ART несет некоторые изменения для GC.  

Не надо ляля. Ручное управление памятью бесспорно быстрее и эффективнее GC, вопрос только - насколько? Чем сложнее приложение, чем больше оно требует ресурсов, тем менее приемлем GC.
Знаете ли вы хотя бы один подобный проект, на платформе GC, у которого бы не было проблем с отзывчивостью или скоростью? Я - не знаю.
Доходит до абсурда, тот же FF - у него вроде  GC, но не только медленный и заикается, так еще и память у него течет пропадая.
 

Цитата:
Идея как раз красивая. Подсчет ссылок более проблематичен
Чем?  
 
Тем, чтобы необходимо следить за циркулярными референсами?  
 

Цитата:
слабые ссылки в глобальном списке это - рукалицо.

С использованием слабых ссылок, мы уходим от проблемы утечки, но приходим к   нуль-референс угрозе, когда слабая ссылка ненароком не обнулилась.
Лекарство хуже болезни.
 
Подсчет ссылок лишь подспорье для ручного управления памятью, а вовсе не средство для абстракции от этой задачи.
 
А решение для абстракции - именно достижимость. Интересно, много ли пройдет времени, когда они додумаются скомбинировать эти подходы: делать основную работу подсчетом сильных ссылок, а в фоне эвристиками на основании прекомпилированных данных статического анализа исходного кода, искать кольца -- алгоритмом достижимости либо зачетом ссылок в кольце (когда проверяется гипотеза, что удаление одной структуры влечет удаление всего кольца).
 
 
 
 
Добавлено:

Цитата:
У самой платформы скорее всего есть, на уровне шарпа возможно нет. Например FPC умеет компилировать под JVM - платформу с управляемой памятью и GC - и при этом работают низкоуровневые трюки с указателями и управлением памятью.
 

разумеется. Память - это ведь просто массив, только индексируется он не с нуля, как привыкли скобкокропатели. В рамках этого массива можно организовать менеджер кучи - задача популярная у нас, паскалистов.
Проблема в том, что Шарп и Ява не дают возможности хранить нетривиальные типы в произвольных областях. Это вам не кресты, в которых можно как угодно переопределить оператор new.
 
Добавлено:

Цитата:
 
А в Delphi можно коммитить?

Конечно! Не в компилятор, конечно, но на самом деле туча возможностей, от препроцессинга кода до написания хороших базовых библиотек на замену FMX.  
А можно просто написать хороший учебник по Delphi
вот например  
в статье викиверситета мой вклад больше половины. Мелочь, но если бы нас было 20-100 человек, учебник был бы быстро написан.

Всего записей: 792 | Зарегистр. 24-04-2008 | Отправлено: 00:11 05-01-2015 | Исправлено: AlekXL, 00:30 05-01-2015
kaz_av

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

Цитата:
Не надо ляля.

Действительно - не надо. Будут цифры - можно продолжить разговор. Без цифр это ковыряние в носу.
 

Цитата:
Ручное управление памятью бесспорно быстрее и эффективнее GC

Погугли кому свойственна категоричность суждений.
 

Цитата:
Знаете ли вы хотя бы один подобный проект, на платформе GC, у которого бы не было проблем с отзывчивостью или скоростью? Я - не знаю.  

Я тебе и кучу нативных с такими проблемами назову. А вообще, я пользуюсь одним приложением под mono (Tomboy) и жалоб на него не имею, кроме, разве что, не самого быстрого страта и подъема из фона. Но тот же нативный GoldenDict из фона выбирается тоже не быстро. А уж если говорить о мобильных прилагах, то проблемы у меня лично были только c обезьяньим софтом, весь прочий летает. При всем при этом, я всегда был и остаюсь сторонником нативного софта и прямого управления памятью.
 

Цитата:
Чем?

Непосредственно идеей и механизмом разрешения. Просто и красиво.
 

Цитата:
Лекарство хуже болезни.  

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

Всего записей: 450 | Зарегистр. 15-02-2006 | Отправлено: 00:38 05-01-2015
AlekXL



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

Цитата:
Непосредственно идеей и механизмом разрешения. Просто и красиво

Пузырьковая сортировка тоже проста и красива.
 

Цитата:
Погугли кому свойственна категоричность суждений.  

при чем тут гугл? Мы говорим о потенциале. Грамотное ручное управление лучше любого автомата, потому что человек умнее любого автомата, когда дело доходит до сложных проблем. Это аксиома.

Цитата:
я пользуюсь одним приложением под mono (Tomboy)  


Цитата:
нативный GoldenDict  
ну это черрипикинг. Ты берешь хороший/лучший пример GC против плохого/худшего примера натива.
А ты возьми лучший пример GC и лучший пример ручного управления. Догадываешься, каким будет результат? Вот об этом то я и говорю.
 

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

Цитата:
Вот и подумай, так ли порочна идея...  

мало того, что GC снижает порог вхождения, разрешая небрежный код, так еще хороший код GC замедляет. Скрывает разницу. Кропателям это на руку, а гикам?
 
Добавлено:
А еще GC порочен потому, что понимание его ущербности приходит слишком поздно, когда в проект уже вложено тысячи человеко-часов.

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

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

Цитата:
при чем тут гугл?

Ладно, не хочешь гуглить... Категоричность суждений свойственна невеждам (с).

Цитата:
Это аксиома.  

Только в твоей теории. Но по красоте теорий, теория GC не оставит камня на камне от твоей теории Операция выделения памяти для GC это изменение указателя и только, а это очень дешевая операция даже по сравнению с менеджерами памяти основанными на пулах. GC доступна статистика работы приложения, и он может подстраивать собственные эвристики для более качественного выполнения работы. У GC нет проблемы с циклическими ссылками и фрагментацией памяти. GC более cache friendly, чем подсчет ссылок. Это если говорить о теории. А на практике ты можешь запустить ProcessExplorer и посмотреть сколько времени в работе дотнет-приложения занимает работа GC - смешные цифры.
 

Цитата:
Ты берешь хороший/лучший пример GC против плохого/худшего примера натива.  

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

Цитата:
Догадываешься, каким будет результат?

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

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

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

Цитата:
 
мало того, что GC снижает порог вхождения, разрешая небрежный код, так еще хороший код GC замедляет

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

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

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

Всего записей: 450 | Зарегистр. 15-02-2006 | Отправлено: 11:01 05-01-2015 | Исправлено: kaz_av, 11:02 05-01-2015
SuPriTo



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

Цитата:
Ручное управление памятью бесспорно быстрее и эффективнее GC, вопрос только - насколько? Чем сложнее приложение, чем больше оно требует ресурсов, тем менее приемлем GC.

Сейчас делаю проект на C#. Пишу робота для торговли на бирже. И вот я уже задолбался с этим сборщиком мусора. Когда идет большой массив данных, постоянные тормоза. Плюс я использую внешнюю библиотеку и постоянно думаю, почистилась память или не почистилась. Но по ходу видимо не почистилась, а может еще какие-то ссылки есть. И это постоянно в каких-то терзаниях по поводу автоматической сборки мусора.

Цитата:
Проблема в том, что Шарп и Ява не дают возможности хранить нетривиальные типы в произвольных областях.

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

Цитата:
Только в твоей теории.

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

Цитата:
А на практике ты можешь запустить ProcessExplorer и посмотреть сколько времени в работе дотнет-приложения занимает работа GC - смешные цифры.  

Эти смешные цифры в неподходящее время могут быть совсем не смешными.

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

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

Цитата:
А сделать что-то весьма нелегко -- либо рефакторить всё, все явные и неявные выделения памяти, боксинг и т.д в цикле обработки и соседних нитях . Либо писать демона в отдельном контексте, и желательно, не на GC-платформе.  

Вот это как раз на практике так и получается.
 

Всего записей: 1484 | Зарегистр. 24-03-2009 | Отправлено: 12:06 05-01-2015 | Исправлено: SuPriTo, 12:16 05-01-2015
kaz_av

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

Цитата:
И приходится транить большое кол-во часов на то, чтобы все это дело оптимизировать

А эффективный код за минуту не пишется. Нигде и никогда.
 

Цитата:
А когда используешь сторонние библиотеки это превращается в целый кошмар, т.к. в сторонней библиотеке мало кто об этом задумывается.  

Для натива тут вообще смерть - сторонний код есть потенциальный источник самых невероятных граблей.
 

Цитата:
Эти смешные цифры в неподходящее время могут быть совсем не смешными.  

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

Цитата:
Конечно он может, но от пауз не избавляет, видимо пока его самого не перепишешь (это мои предположения).  

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

Цитата:
Вот это как раз на практике так и получается.  

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

Цитата:
Сейчас делаю проект на C#. Пишу робота для торговли на бирже. И вот я уже задолбался с этим сборщиком мусора.

А чего, кстати, не на дельфях пишешь?

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



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

Цитата:
Для натива тут вообще смерть - сторонний код есть потенциальный источник самых невероятных граблей.  

Ой, ли. Для натива много всяких возможностей обойти грабли.

Цитата:
А чего, кстати, не на дельфях пишешь?

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

Цитата:
Ну вот как раз такие разочарования в GC и случаются у людей считающих его серебряной пулей.

Я не считаю его серебряной пулей, я его считаю некоторой проблемой, с которой приходится сталкиваться.
Если в делфи или на си я просто выделил память, то я знаю, что эту память нужно очистить. Когда и где это мои личные проблемы от меня зависящие. В GC у меня вечный вопрос, а почистилась ли память или нет? А почистилась ли память во внутренних структурах библиотеки, т. к. она сложна и т. д. Ответ в делфи на этот вопрос решается одной строкой, а в GC это сбор и исследование статистики. И походу придумывание различных граблей для анализа статистики. Для простых приложений GC подходящая может очень подходящая штука. Но я привык работать так - выделил, почистил и забыл. А GC в этом смысле предлагает массу различных вариантов.

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

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

Всего записей: 1484 | Зарегистр. 24-03-2009 | Отправлено: 12:54 05-01-2015 | Исправлено: SuPriTo, 12:55 05-01-2015
kaz_av

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

Цитата:
Ой, ли. Для натива много всяких возможностей обойти грабли.  

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

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

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

Цитата:
 В GC у меня вечный вопрос, а почистилась ли память или нет? А почистилась ли память во внутренних структурах библиотеки, т. к. она сложна и т. д. Ответ в делфи на этот вопрос решается одной строкой, а в GC это сбор и исследование статистики.

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

Цитата:
Так вот это уже приходится в этом вопросе разбираться и тратить кучу времени на это. Как и что у него работает.

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

Всего записей: 450 | Зарегистр. 15-02-2006 | Отправлено: 13:36 05-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 324 325 326 327

Компьютерный форум 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