Попробовал увеличить copy_buffer_size в KFAR с 65 кбайт до 8 мбайт, и сравнить все это с тем, что имеется в системе.
Проверял в QEMU с образом диска в FAT16, копировал из /bd0/1/ в подпапку на /hd0/1/
Прошу прощения за то, что размеры файлов "нестандартные". Старался проверять на условиях, приближенных к реальности.
Результаты тестов:
1) Копирование 15 файлов, общий размер 122 МБ
KFAR: 31 секунда
KFM: 20 секунд
KFAR (8mb buffer): 20 секунд
2) Копирование одного файла размером больше, чем ОЗУ и буфер - 293 Мб. ОЗУ - 128 мегабайт
KFAR: 292 секунды. Использование памяти системой - 11%
KFM:копировал два раза. Первый - 80 секунд, второй - 86. Использование памяти - 33%
KFAR (8 mb buffer): копировал два раза. Первый - 68, второй - 92. Использование памяти - 18%
3) Копирование одного файла размером 293 Мб. ОЗУ - 640 мегабайт
KFAR: 298 секунд.Использование памяти 3%
KFM: первый раз 72, второй - 76 секунд. Использование памяти 27%
KFAR (8 mb buffer) - первый раз 50, второй раз - 79 секунд. Использование памяти 4%
KFAR - полноценный файловый менеджер
Qemu не показатель. Ты копировал в KFAR после KFM и довольно большой кусок данных (главное что это служебные данные файловой системы) был уже закеширован хостовой системой (той в которой Qemu запущен). Объективные результаты получаются только на реальной машине. И они таковы - чем больше памяти выделено, тем быстрее копируется. Однако Колибри имеет ограниченный размер кеша в 1Мб на одно физическое устройство и выше определенного размера буфера скорость растет уже незначительно.
Примерно так я себе это и представлял. В любом случае, вполне реально можно получить бОльшие результаты в KFAR, чем те, что сейчас получаются. И это для меня важно.
Завтра или послезавтра проверю на реальной машине, пока что под рукой нет fat32-дисков.
Завтра или послезавтра проверю на реальной машине, пока что под рукой нет fat32-дисков.
Провел тесты, как и обещал, на реальной машине.
В среднем скорость копирования в KFAR с увеличенным буфером возрастает в несколько раз по сравнению со скоростью в официальной версии, и если файлы небольшие, то приближается к скорости KFM.
Но! Стоит начать копировать папку с подпапками - начинается тихий ужас. Папка с десятком вложенных подпапок общим весом около 5 мегабайт копируется порядка минуты, в то время как один файл весом 5 мегабайт копируется за 1 секунду в KFM и за 3-5 в KFAR.
В среднем скорость копирования в KFAR с увеличенным буфером возрастает в несколько раз по сравнению со скоростью в официальной версии, и если файлы небольшие, то приближается к скорости KFM.
Но! Стоит начать копировать папку с подпапками - начинается тихий ужас. Папка с десятком вложенных подпапок общим весом около 5 мегабайт копируется порядка минуты, в то время как один файл весом 5 мегабайт копируется за 1 секунду в KFM и за 3-5 в KFAR.
Paragon'овский (и Winternalsовский) драйвер для DOS отлично фиксят такие разделы. В смысле, их ntfsfix исправляет ошибки, потом можно из под любой оси скопировать. Однако ж, я бы предварительно снял raw образ диска.Sorcerer wrote:Колибри - это моя единственная надежда спасти 120 гигабайт данных. Нтфс-диск, с которого данные может прочесть лишь Колибри - а другие ОС при попытке чтения с диска умирают
А почему KFM нет в svn-репозитарии? Потому что лицензия не GPL?
ушёл...
Потому что я не заливал, diamond тоже кстати не заливал на SVN - однажды это сделали за него (чем кстати он был не очень доволен, по крайней мере мне так показалось).
Ну, а я тогда воевал на всех фронтах.
З.Ы, Просьба не заливать KFM и дальше - ибо будет переписан с нуля. И да лицензия у текущего BSD, о чем я уже упоминал на форуме.
Ну, а я тогда воевал на всех фронтах.
З.Ы, Просьба не заливать KFM и дальше - ибо будет переписан с нуля. И да лицензия у текущего BSD, о чем я уже упоминал на форуме.
Выделил эту тему из Проект: Полноценный файловый менеджер - по идее такое надо было сделать уже давно. Потому что начало темы лишь немного связано с KFAR было, а все дальнейшее обсуждение касалось исключительно KFAR. Да и нагляднее так - название темы содержит название программы.
SVN r. 2633 в редактор добавлена корректная обработка системных горячих комбинаций Alt+Tab и Shift+Alt+Tab.
1. Из Просмотра текста невозможно перейти в режим Редактирования.
2. При прокрутке текста "залипают" клавиши. У меня не получилось исправить, используя фикс Gluka.
2. При прокрутке текста "залипают" клавиши. У меня не получилось исправить, используя фикс Gluka.
Spoiler:
Code: Select all
key:
mov al, 2
int 40h ;leency {
;Leency[
cmp al,1
jne .getkeyi
mov ah,dh
jmp .next
.getkeyi:
mov dh,ah
jmp key
.next: ;]Leency
Из хаоса в космос
"Залипают" в том смысле, что продолжает некоторое время выполнять после опускания клавиши? ЕМНИП автор был против таких методов. "Все события должны быть обработаны" что то в этом духе.
Да, в этом смысле. Ну да ладно. Я первое сообщение отредактировал - там ещё один глюк.
Из хаоса в космос
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Если начать копировать папку в себя саму KFAR падает.
Из хаоса в космос
W7 проводник говорит что так делать нельзя, а UnrealCommander просто молча игнорит.Leency wrote:Если начать копировать папку в себя саму KFAR падает.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Who is online
Users browsing this forum: No registered users and 1 guest