Comments 35
Оригинальный подход, молодец (:
Если сделать подобное в 3D и с размером шаров, пропорциональным размеру директорий или количеству файлов в них, получится прикольная утилита для анализа засорённости файлопомойки.
Если сделать подобное в 3D и с размером шаров, пропорциональным размеру директорий или количеству файлов в них, получится прикольная утилита для анализа засорённости файлопомойки.
Спасибо.
Про соответствие шаров размеру идея тоже приходила в голову, а про 3D нет.
Надо будет попробовать. Возможно на чем то более мощном, чем питон. Он крут для быстрого создания прототипов, но пока я не смог заставить змия быстро работать.
Про соответствие шаров размеру идея тоже приходила в голову, а про 3D нет.
Надо будет попробовать. Возможно на чем то более мощном, чем питон. Он крут для быстрого создания прототипов, но пока я не смог заставить змия быстро работать.
Не соглашусь, здесь не питон будет узким местом.
Скорость работы будет, в основном, определяться скоростью работы с файловой системой.
Расход памяти будет большим в любом случае, и, большей частью, будет определяться потреблением networkx — все-таки число узлов огромное.
Скорость работы будет, в основном, определяться скоростью работы с файловой системой.
Расход памяти будет большим в любом случае, и, большей частью, будет определяться потреблением networkx — все-таки число узлов огромное.
Да, проблема памяти существенна. Возможно, надо сбрасывать данные на диск, по мере увеличения графа. Но возникнет вопрос как потом вывести единый результат.
Немного потестил на 10 000 ребер (случайное соединение между 10 000 узлами).
Много времени уходит на построение самого графа. В коде это строка:
При этом было съедено около 50Mb памяти и потребовалось около получаса на построение.
Так что здесь все больше упирается в процессорное время, а не в память.
Много времени уходит на построение самого графа. В коде это строка:
nx.draw(G, with_labels=False, node_color="blue", alpha= 0.6, node_size=50)
При этом было съедено около 50Mb памяти и потребовалось около получаса на построение.
Так что здесь все больше упирается в процессорное время, а не в память.
И питон потянет, Вы просто не умеете его готовить.
Когда работаете с такими вещами, думаю и на C пришлось бы оптимизировать. Нечего весь disk tree в память структурой пихать :).
Жаль 3д мне не дается, так бы мог бы помочь.
Когда работаете с такими вещами, думаю и на C пришлось бы оптимизировать. Нечего весь disk tree в память структурой пихать :).
Жаль 3д мне не дается, так бы мог бы помочь.
Очень напоминает стандартный убунтовский «Анализатор использования дисков». Но последний кроме прочего умеет работать по сети (FTP, SSH, SMB и др.)
классно, но вот шарики в 3D бы реализовать, так вообще просто круто было бы :)
Возможно, он не по каталогам ползет, а сразу читает Master File Table? Хотя, надо взглянуть на исходники.
w3.win.tue.nl/nl/onderzoek/onderzoek_informatica/visualization/sequoiaview/
Прикольный софт, квадратами всё кажет…
Прикольный софт, квадратами всё кажет…
Интересное применение networkx.
Сейчас сам с ней работаю. Мы ее используем для построения схемы сети — дает очень хорошую картинку.
Сейчас сам с ней работаю. Мы ее используем для построения схемы сети — дает очень хорошую картинку.
Для анализа использования диска есть крутая тулза baobab (Disk Usage Analyzer). Во многих дистрах есть по дефолту
Я все задачи визуализации графов делаю с помощью graphviz. На питоне скрипты пишут текстовые файлы типа
и кормят их приложению graphviz. Полный контроль над внешним видом графов, надписи в узлах и на ребрах и генерация тегов AREA MAP и много еще чего. Правда операций линейной алгебры и теории графов не поддерживает. Не нужно держать в памяти весь граф дисковой системы — по мере обхода дерева просто пишешь в файл. А graphviz очень хорошо справляется с большими графами, правда может сгенерить простыню на 100Мб (графический файл PNG или JPEG).
Спасибо за наводку — попробую networkx тоже.
A -> B
B -> C
B -> D
и кормят их приложению graphviz. Полный контроль над внешним видом графов, надписи в узлах и на ребрах и генерация тегов AREA MAP и много еще чего. Правда операций линейной алгебры и теории графов не поддерживает. Не нужно держать в памяти весь граф дисковой системы — по мере обхода дерева просто пишешь в файл. А graphviz очень хорошо справляется с большими графами, правда может сгенерить простыню на 100Мб (графический файл PNG или JPEG).
Спасибо за наводку — попробую networkx тоже.
Зачем 'кормить' их приложению graphviz, можно напрямую
import gv
g = gv.graph('tree')
a = gv.node(g, 'A')
b = gv.node(g, 'B')
e = gv.edge(a, b)
…
gv.layout(g, 'dot')
gv.render(g, file_format, filename)
import gv
g = gv.graph('tree')
a = gv.node(g, 'A')
b = gv.node(g, 'B')
e = gv.edge(a, b)
…
gv.layout(g, 'dot')
gv.render(g, file_format, filename)
PS. И лучше в формате PDF или SVG, тогда не будет 'на 100Мб (графический файл PNG или JPEG)'.
Использую NetworkX для проекта. Очень хорош в паре с InfoViz (JS библиотека для визуализации графов) thejit.org/

D:/Работа/Документы/Старое/Всякий хлам/Нужно удалить/zzzzz/asfsdsfs/Порно? :)
Нее, труъ-ниндзя хранят порно в шифрованных многотомных архивах, разбросанных по разным дискам и замаскированных под DLL, EXE, SYS и прочие файлы, уже своим названием кричащие о своей неприкосновенности :)
Как найти давно спрятанные и забытые кучи добротного порно при помощи визуализцации списка каталогов, как граф.
После прочтения сразу потянуло взять Python + NetworkX и тоже чего нибудь сбацать.
ИМХО, с помощью Python нужно собирать/парсить данные и генерировать графы в одном из общепринятых форматов, а анализировать результаты удобнее в Gephi
Sign up to leave a comment.
Визуализация каталогов на Python средствами NetworkX