@erua Кек, сделал бы вид, что понял, но нед :(

@𝕵𝖔𝖍𝖆𝖓 ⛧ ну посыл в том, что железо у тебя говно дешёвое — т.е. утомить можно любого, даже те дешёвенькие SSD, которые NVME — обычные или с DRAM-кешем.

т.е. всегда, именно ВСЕГДА, важным и большим вопросом является контроллер внутри SSD. прямо аж с 2015-2016 годов, когда это были SATA-диски. ограниченные по скорости пропускной способностью SATA-интерфейса.
тот факт что ты купил SSD — это не волшебный талисман против подтупливания софта на дисковых операциях.

современные «диски» (NVME) вставляемые через m.2- или PCI-разъёмы имеют хорошие скорости при различных видах доступа (потоковый, случайный), в разы большие чем в случае с SATA-интерфейсом, а за счёт чего?
принципиально ничегошеньки не поменялось, те же беды для контроллеров, но только забот добавилось, потому как ячейки памяти удешевили ради повышения ёмкости носителей. из-за чего контроллерам приходится куда как более аккуратно работать в плане распределения нагрузки по ячейкам. да и запись-чтение идёт уже доменами, опять же в следствии увеличения ёмкости. что тоже добавляет сложности в работу контроллера.

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

если не хочешь такого, то пиздыхай плиз в магхазын и плати бабос за модель с другим контроллером, более разумным, башкавитым и производительным.
а раз съэконил $15 при покупке, то вот теперь ебись с настройками своей операционки, чтобы она не допускала определённых видов нагрузки на этот самый SSD/NVME носитель, тогда и не будет таких вот подтупливаний. и не факт, что будет 100% результат.

@erua Как боженька смолвил 🙂

Трабла в том, что подвисает ТОЛЬКО этот менеджер, explorerom можно свободно пользоваться (но не нужно и не хочется).

@𝕵𝖔𝖍𝖆𝖓 ⛧ всегда ли подвисает? вот в чём вопрос.
т.е. крутить ли настройки в этом твоём «менеджере», чтобы иначе как-то сканировал файловую систему для создания миниатюр — иконок представления тех файлов и каталогов, которые собирается отобразить пользователю в диалоге.
может он резко начинает открывать 100500 файлов на чтение, чтобы вычитать с них данные ради этих миниатюр.
тогда при открытии одних фолдеров будет подвисать меньше, чем при открытии диалога внутри другой части файловой системы.

@erua Не, всё немного интереснее. Подвисает ВСЕГДА, если скопировать с флешки/из мессенджера буквально пару вордовских файлов. При этом папка, куда скинули, создана не из него и в нём не открыта. И режим отображения «тупо список», да и особо меты всякой он не умеет.

...И тем временем в фоне венда стопудово создает, пишет и удоляет сотни файлов, это почему-то не влияет.

Поэтому мой кругозор упирается в вопрос «если тестировать — то что вообще».

@𝕵𝖔𝖍𝖆𝖓 ⛧ ну моё первое же сообщение в этом треде начинается словами:
«так понял, что это не всегда, а лишь иногда. т.е. дело не в самой по себе GUI подсистеме (очередях сообщений сквозь иерархию окон-контролов).»
Теперь же выясняется, что тормозит таки всегда.
Значит надо смотреть на такой момент — если на компе достаточно много свободной оперативной памяти. Ну типа он сразу после перезагрузки и другой файловый менеджер уже работал с этой папкой/фолдером/директорией, то значит она должна быть закэширована в оперативке. Для этого кэша используется та часть ОЗУ, которая сейчас не занята никакими приложениями.
Вот после этого подозреваемый в тормозах должен легко и просто работать с этой же частью файловой системы, потому что оно всё уже в кэше ОС.

Если же ему посрать на это всё — на большое количество свободного ОЗУ в свеже рестарченной машине, что с файлами этими уже кто-то до него работал и они в кеше. Тогда значит дело в том как VCL отрабатывает в твоей системе, поскольку борландовская VCL или BCL фактически является охрененно жирной прослойкой между приложением и системными вызовами API торчащими из ОС для прикладного софта.