#Вопрос: Если #CubicExplorer (да, сцуко, на Delphi, но заявлено (10 лет назад), что прям компоненты рендерят fileview быстрее, чем в венде), прям подтупливает на пару секунд, если что-то писалось на SSD. Куда копать?
На очень разных машинах его использую, такого глюка никогда не видел. Заранее благодарю за уделенное/потраченное время.
@𝕵𝖔𝖍𝖆𝖓 ⛧ так понял, что это не всегда, а лишь иногда. т.е. дело в GUI подсистеме (очередях сообщений сквозь иерархию окон-контролов пропихиваемых).
соответственно, смотреть очередь на диск какая в этот момент? и небось TRIM включён? т.е. конкуренция со стороны разного софта затыкает и контроллер на SSD диске, во время выполнения реструктуризации доменов и очередь в системе (кэш дисковых операций в ОС) вместе дают такой эффект.
т.е. получается две очереди, одна в ядре ОС реализующая кэширование дисковых операций, а вторая очередь на контроллере SSD-диска, у которого если имеется DRAM-кэш, то тот уже забит + надо выполнить реструктуризацию блоков, которыми хранит данные — это сродни перекэшированию при изменении размера хеш-таблицы.
соответственно, смотреть очередь на диск какая в этот момент? и небось TRIM включён? т.е. конкуренция со стороны разного софта затыкает и контроллер на SSD диске, во время выполнения реструктуризации доменов и очередь в системе (кэш дисковых операций в ОС) вместе дают такой эффект.
т.е. получается две очереди, одна в ядре ОС реализующая кэширование дисковых операций, а вторая очередь на контроллере SSD-диска, у которого если имеется DRAM-кэш, то тот уже забит + надо выполнить реструктуризацию блоков, которыми хранит данные — это сродни перекэшированию при изменении размера хеш-таблицы.
@erua Кек, сделал бы вид, что понял, но нед :(
@𝕵𝖔𝖍𝖆𝖓 ⛧ ну посыл в том, что железо у тебя говно дешёвое — т.е. утомить можно любого, даже те дешёвенькие SSD, которые NVME — обычные или с DRAM-кешем.
т.е. всегда, именно ВСЕГДА, важным и большим вопросом является контроллер внутри SSD. прямо аж с 2015-2016 годов, когда это были SATA-диски. ограниченные по скорости пропускной способностью SATA-интерфейса.
тот факт что ты купил SSD — это не волшебный талисман против подтупливания софта на дисковых операциях.
современные «диски» (NVME) вставляемые через m.2- или PCI-разъёмы имеют хорошие скорости при различных видах доступа (потоковый, случайный), в разы большие чем в случае с SATA-интерфейсом, а за счёт чего?
принципиально ничегошеньки не поменялось, те же беды для контроллеров, но только забот добавилось, потому как ячейки памяти удешевили ради повышения ёмкости носителей. из-за чего контроллерам приходится куда как более аккуратно работать в плане распределения нагрузки по ячейкам. да и запись-чтение идёт уже доменами, опять же в следствии увеличения ёмкости. что тоже добавляет сложности в работу контроллера.
отсюда и вся беда — тебе нужен дешёвеньки SSD? получай хероту с время от времени подтупливающим контроллером, из-за чего иногда проседает время доступа к данным — после определённого вида нагрузок на этот самый носитель. когда не дали ему время в себя прийти.
если не хочешь такого, то пиздыхай плиз в магхазын и плати бабос за модель с другим контроллером, более разумным, башкавитым и производительным.
а раз съэконил $15 при покупке, то вот теперь ебись с настройками своей операционки, чтобы она не допускала определённых видов нагрузки на этот самый SSD/NVME носитель, тогда и не будет таких вот подтупливаний. и не факт, что будет 100% результат.
т.е. всегда, именно ВСЕГДА, важным и большим вопросом является контроллер внутри SSD. прямо аж с 2015-2016 годов, когда это были SATA-диски. ограниченные по скорости пропускной способностью SATA-интерфейса.
тот факт что ты купил SSD — это не волшебный талисман против подтупливания софта на дисковых операциях.
современные «диски» (NVME) вставляемые через m.2- или PCI-разъёмы имеют хорошие скорости при различных видах доступа (потоковый, случайный), в разы большие чем в случае с SATA-интерфейсом, а за счёт чего?
принципиально ничегошеньки не поменялось, те же беды для контроллеров, но только забот добавилось, потому как ячейки памяти удешевили ради повышения ёмкости носителей. из-за чего контроллерам приходится куда как более аккуратно работать в плане распределения нагрузки по ячейкам. да и запись-чтение идёт уже доменами, опять же в следствии увеличения ёмкости. что тоже добавляет сложности в работу контроллера.
отсюда и вся беда — тебе нужен дешёвеньки SSD? получай хероту с время от времени подтупливающим контроллером, из-за чего иногда проседает время доступа к данным — после определённого вида нагрузок на этот самый носитель. когда не дали ему время в себя прийти.
если не хочешь такого, то пиздыхай плиз в магхазын и плати бабос за модель с другим контроллером, более разумным, башкавитым и производительным.
а раз съэконил $15 при покупке, то вот теперь ебись с настройками своей операционки, чтобы она не допускала определённых видов нагрузки на этот самый SSD/NVME носитель, тогда и не будет таких вот подтупливаний. и не факт, что будет 100% результат.
@erua Не, всё немного интереснее. Подвисает ВСЕГДА, если скопировать с флешки/из мессенджера буквально пару вордовских файлов. При этом папка, куда скинули, создана не из него и в нём не открыта. И режим отображения «тупо список», да и особо меты всякой он не умеет.
...И тем временем в фоне венда стопудово создает, пишет и удоляет сотни файлов, это почему-то не влияет.
Поэтому мой кругозор упирается в вопрос «если тестировать — то что вообще».
@𝕵𝖔𝖍𝖆𝖓 ⛧ ну моё первое же сообщение в этом треде начинается словами:
«так понял, что это не всегда, а лишь иногда. т.е. дело не в самой по себе GUI подсистеме (очередях сообщений сквозь иерархию окон-контролов).»
Теперь же выясняется, что тормозит таки всегда.
Значит надо смотреть на такой момент — если на компе достаточно много свободной оперативной памяти. Ну типа он сразу после перезагрузки и другой файловый менеджер уже работал с этой папкой/фолдером/директорией, то значит она должна быть закэширована в оперативке. Для этого кэша используется та часть ОЗУ, которая сейчас не занята никакими приложениями.
Вот после этого подозреваемый в тормозах должен легко и просто работать с этой же частью файловой системы, потому что оно всё уже в кэше ОС.
Если же ему посрать на это всё — на большое количество свободного ОЗУ в свеже рестарченной машине, что с файлами этими уже кто-то до него работал и они в кеше. Тогда значит дело в том как VCL отрабатывает в твоей системе, поскольку борландовская VCL или BCL фактически является охрененно жирной прослойкой между приложением и системными вызовами API торчащими из ОС для прикладного софта.
«так понял, что это не всегда, а лишь иногда. т.е. дело не в самой по себе GUI подсистеме (очередях сообщений сквозь иерархию окон-контролов).»
Теперь же выясняется, что тормозит таки всегда.
Значит надо смотреть на такой момент — если на компе достаточно много свободной оперативной памяти. Ну типа он сразу после перезагрузки и другой файловый менеджер уже работал с этой папкой/фолдером/директорией, то значит она должна быть закэширована в оперативке. Для этого кэша используется та часть ОЗУ, которая сейчас не занята никакими приложениями.
Вот после этого подозреваемый в тормозах должен легко и просто работать с этой же частью файловой системы, потому что оно всё уже в кэше ОС.
Если же ему посрать на это всё — на большое количество свободного ОЗУ в свеже рестарченной машине, что с файлами этими уже кто-то до него работал и они в кеше. Тогда значит дело в том как VCL отрабатывает в твоей системе, поскольку борландовская VCL или BCL фактически является охрененно жирной прослойкой между приложением и системными вызовами API торчащими из ОС для прикладного софта.
т.е. крутить ли настройки в этом твоём «менеджере», чтобы иначе как-то сканировал файловую систему для создания миниатюр — иконок представления тех файлов и каталогов, которые собирается отобразить пользователю в диалоге.
может он резко начинает открывать 100500 файлов на чтение, чтобы вычитать с них данные ради этих миниатюр.
тогда при открытии одних фолдеров будет подвисать меньше, чем при открытии диалога внутри другой части файловой системы.