Здравствуйте, inevity, Вы писали:
I>Здравствуйте, друзья!
I>Заранее прощу прощения! Я сам тракторист, но черт меня дернул заняться программированием(еще и на паскале). Опишу ситуацию по мере сил. I>Но надеюсь опытные спецы без особого труда подскажут хотя бы где искать проблему.
I>Проблема:........
Здравствуйте, cures, Вы писали:
C>Здравствуйте, Sinix, Вы писали:
WH>>>В .NET своя куча в каждом потоке. S>>Для каждого логического ядра, и то не для всех GC. Там вся аллокация (пока место есть) — один interlocked.Add(), нафиг perThread там не нужен.
C>Ну казалось бы логичным на каждый поток завести свой не очень большой пул, размером с метр, и выделять из него, и только когда кончится место — лочиться и выхватывать у системы новый кусок памяти. Но тогда не менее логичным кажется и в GC чистить прежде всего его, не останавливая другие потоки. А уж как там на самом деле, да ещё в разных реализациях, тем более в Дельфи — я понятия не имею, наверное WolfHound что-то знает и сможет поделиться с нами ссылками.
Меня всегда удивляют такие люди, которые думают, что лучше знают как память выделять \освобождать в реальных программах.
Попробуй для начала ответить на простой вопрос. Если поток А выделил блок памяти, а потом передал в поток В, то как ты будешь сжимать кучу останавливая только А?
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Igorxz, Вы писали:
I>>вот так попробуй в конфиге сделать: S>Не надо играться с шрифтами, пока не определил проблемное место и способ лечения. Не поможет.
S>Server gc тут как зелёнка при гангрене: и так зелёное, и так, разницы никакой.
Чего не надо?!? какая зеленка — это и есть один из способов лечения
Здравствуйте, Igorxz, Вы писали:
S>>Server gc тут как зелёнка при гангрене: и так зелёное, и так, разницы никакой.
I>Чего не надо?!? какая зеленка — это и есть один из способов лечения
Ага-ага.
И аллокации лишние оно уберёт, и тормоза из-за использования List<T> без задания capacity, и обращение к контролам+AppDoEvents в рабочих потоках полечит.
Вы бы хоть код посмотрели для начала