The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Третий релиз консольного файлового менеджера XYZCommander, opennews (??), 18-Янв-10, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


118. "Третий релиз консольного файлового менеджера XYZCommander"  +/
Сообщение от Max E. Kuznecovemail (?), 20-Янв-10, 23:48 
>А каким образом он умудряется так кошмарно тормозить? При входе в большую
>директорию тупит пару секунд ворочая диском - такое чувство, что рекурсивный
>find делает.

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

Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

121. "Третий релиз консольного файлового менеджера XYZCommander"  +/
Сообщение от аноним (?), 21-Янв-10, 00:24 
>Пока он считывает весь список файлов в память, на следующий релиз запланирована
>оптимизация как раз по этому поводу.

Т.е. рекурсивно?! Если так, надо не оптимизировать, а руки отрывать. Вход в директорию не должен быть медленнее ls -l, а в идеале вообще ls (т.е. даже без stat'ов, в панели все равно только список файлов показывается без атрибутов, а для stat'ов нужен простой кэш, чтобы не читать их каждый раз при перемещении курсора).

Ответить | Правка | Наверх | Cообщить модератору

123. "Третий релиз консольного файлового менеджера XYZCommander"  +/
Сообщение от Max E. Kuznecovemail (?), 21-Янв-10, 00:30 
>>Пока он считывает весь список файлов в память, на следующий релиз запланирована
>>оптимизация как раз по этому поводу.
>
>Т.е. рекурсивно?! Если так, надо не оптимизировать, а руки отрывать. Вход в
>директорию не должен быть медленнее ls -l, а в идеале вообще
>ls (т.е. даже без stat'ов, в панели все равно только список
>файлов показывается без атрибутов, а для stat'ов нужен простой кэш, чтобы
>не читать их каждый раз при перемещении курсора).

Не рекурсивно, просто на каждый файл создаётся VFS объект, с которыми потом происходит дальнейшая работа.

Ответить | Правка | Наверх | Cообщить модератору

125. "Третий релиз консольного файлового менеджера XYZCommander"  +/
Сообщение от аноним (?), 21-Янв-10, 00:45 
>Не рекурсивно, просто на каждый файл создаётся VFS объект, с которыми потом
>происходит дальнейшая работа.

Видимо это и тормозит, потому что заход в директорию, содержащую 1800 директорий уже занимает около секунды, даже без чтения диска.

Ответить | Правка | Наверх | Cообщить модератору

126. "Третий релиз консольного файлового менеджера XYZCommander"  +/
Сообщение от Max E. Kuznecovemail (?), 21-Янв-10, 00:51 
>>Не рекурсивно, просто на каждый файл создаётся VFS объект, с которыми потом
>>происходит дальнейшая работа.
>
>Видимо это и тормозит, потому что заход в директорию, содержащую 1800 директорий
>уже занимает около секунды, даже без чтения диска.

Безусловно, не зря же я говорил про оптимизацию. Сейчас это просто стандартный питоновский список. Хочу заменить его на нечто вроде ленивого списка, чтоб читал и создавал объекты только по мере необходимости. Кроме выигрыша в скорости также получаем выигрыш по памяти.

Ответить | Правка | Наверх | Cообщить модератору

128. "Третий релиз консольного файлового менеджера XYZCommander"  +/
Сообщение от аноним (?), 21-Янв-10, 01:11 
Блин, не думал что питон столько времени тратит на создание 2k объектов.
Ответить | Правка | Наверх | Cообщить модератору

129. "Третий релиз консольного файлового менеджера XYZCommander"  +/
Сообщение от Max E. Kuznecovemail (?), 21-Янв-10, 01:17 
>Блин, не думал что питон столько времени тратит на создание 2k объектов.
>

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

Ответить | Правка | Наверх | Cообщить модератору

133. "Третий релиз консольного файлового менеджера XYZCommander"  +/
Сообщение от a (??), 21-Янв-10, 15:46 
>Ну даже mc не моментально входит в каталоги с большим количеством файлов, а тут уж прйдётся только такими окольными путями оптимизировать.

Вот окольными путями здесь лучше не надо. А то получится то, о чем уже шла речь выше про оптимизацию.

Уже существует достаточное количество хорошо зарекомендовавших себя паттернов, связанных с разделением данных и представлений.

Тем более, в двухпанельном редакторе интерфейс достаточно фиксированный.

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

134. "Третий релиз консольного файлового менеджера XYZCommander"  +/
Сообщение от syhpoonemail (ok), 21-Янв-10, 16:01 
>[оверквотинг удален]
>
>Всякое там кеширование еще захочется вставить и пошло-поехало все это между собой
>перевязывать. А сложность растет комбинаторно, если не предпринимать мер по развязке
>подсистем.
>
>Пользователям, вечно жалующимся на скорость, все равно никогда не угодите и впечатление
>на них никогда не произведете, потому что они всегда лучше знают,
>как надо было делать. А вот проглядеть изящные решения очень легко,
>если слишком торопиться с оптимизацией. А обратно откатывать - пользователи еще
>сильнее жаловаться начнут, что их любимый функционал убрали.

Ну собственно ленивая вычитка как раз один из таких известных паттернов, когда есть большое количество данных но одновременно отображается только небольшое их подмножество, и вычитывать файлы по мере надобности вполне приемлемое решение, оно никак не повлияет на внешний функционал но существенно увеличит скорость входа в каталоги с большим количеством файлов.
Этот тикет у меня чуть ли ни с первой версии висит ещё :)

Ответить | Правка | Наверх | Cообщить модератору

135. "Третий релиз консольного файлового менеджера XYZCommander"  +/
Сообщение от a (??), 22-Янв-10, 01:08 
Попробуем еще рассуждать от противного.

Был, знаете ли, раньше один такой мыслитель и практик по имени Противный. Его именем потом и назвали этот вид рассуждений.

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

Поэтому многие спешат поставить знак равенства между противным и уродливым. Однако если спешить с каждым соглашаться, как раз скорее всего уродство и получится.

Так вот, рассуждения от Противного.

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

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

Потому большинство в первую очередь это и реализуют.

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

Не лучше ли сосредоточиться на том поиске и понимании того, в чем ваша уникальность и в чем ваше преимущество. При понимании этого и при РЕАЛИЗАЦИИ собственных преимуществ и талантов, все остальное достигается без особых усилий.

Чем больше ваш проект будет набирать известности, тем больше будет появляться тех, кто будет заявлять, что у вас что-то не так.

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

Ответить | Правка | Наверх | Cообщить модератору

136. "Третий релиз консольного файлового менеджера XYZCommander"  +/
Сообщение от Max E. Kuznecovemail (?), 22-Янв-10, 01:52 
С другой стороны, если функционалом программы является, по сути, навигация по каталогам, и есть явное узкое место, почему бы его не убрать? И это совсем не потакание или ещё что, нельзя же заняв круговую оборону сидеть и принимать в штыки  любое предложение со стороны пользователей ( я не про конфиги :), только ради принципа что разработчику виднее. Я прислушиваюсь к пожеланиям, но стараюсь фильтровать по собственным критериям ценности.
Ответить | Правка | Наверх | Cообщить модератору

137. "Третий релиз консольного файлового менеджера XYZCommander"  +/
Сообщение от a (??), 22-Янв-10, 02:57 
Это не мой проект. Я лишь привел альтернытивные критерии по отношению к банальным критериям потребительской полезности и функциональности.

>С другой стороны, если функционалом программы является, по сути, навигация по каталогам,

Если целью является создание именно средство для навигации по каталогам, тогда все конечно уже решено.

Если целью является создание более абстрактного интерфейса для облегчения полу-ручных операций типа "источник-назначение", для работы с абстрактными _парами_ объектов и в качестве логического продолжения абстраткных потоковых моделей и композиций автоматов, на базе которых построены утилиты и консоль Юникса. Тогда лучше не спешить с определением, где именно может возникнуть узкое место.

Отправной точкой в любом случае является интерфейс пользователя. Иначе зачем вообще нужны эти две панели. Вопрос к чему этот интерфейс планируктся прикладывать. Просто к файловой системе? Однако ФС сама по себе является абстрактной моделью данных.

В качестве примера можно привести Far и Total Commander. Потенциал применения там гораздо шире, чем просто файловая система. Однако изначальная сильная привязанность к конкретным API, а не к моделям, вызывает такие муки с плагинами. Хотя некоторым эти плагины кажутся верхом совершенства.

>и есть явное узкое место, почему бы его не убрать?

Если это не вызывает внутренних противоречий, то почему бы не убрать, да.

>И это совсем не потакание или ещё что, нельзя же заняв круговую оборону сидеть и принимать в штыки  любое предложение со стороны пользователей ( я не про конфиги :),

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

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

>только ради принципа что разработчику виднее.

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

>Я прислушиваюсь к пожеланиям, но стараюсь фильтровать по собственным критериям ценности.

А как можно сформировать собственные критерии ценности, если прислушиваться к чужим пожеланиям. Ценности и формируются из желаний. Чужие желания - чужие ценности.

Я всего лишь привел критерии для понимания собственной _самостоятельности_ в принятии решений. Есть проекты, которые движутся преимущественно ПОЖЕЛАНИЯМ пользователей. Есть проекты, которые движутся преимущественно ПОЖЕЛАНИЯМИ создателей.

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

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

Еще раз, здесь нет никаких руководств к действиям. Это всего лишь критерии к самопониманию и пониманию своего творчества.

А также кое-какие идеи, которые ни к чему не обязывают.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру