ZebroidФорумПубличный разделПредложенияАрхивСкорость работы Зеброида

Скорость работы Зеброида

13 октября 2009, 10:20
Зарегистрирован: 11 июля 2009, 11:46
Мой конфиг компа phenom AMD Phenom x4 2.2 / 4гига памяти / windows 7 x64

Проект:



Запустил поиск дублей статей и Зеюроид задумался на долго, оставил его на ночь и в общей сложности он искал дубли около 9-10 часов в это время на компе ничего не было запущено, приоритет Зеброиду стоял высокий.

Смотрел статистику нагрузки на CPU и как я понял, то используется только одно ядро так как у меня было нагружено только одно ядро и оставшиеся 3 стояли почти без дела. Может я и ошибаюсь но мне кажется, что работать с многоядерными процессорами Зеброид не умеет? + я бы с удовольствием отдал на выполнения задач Зеброидом гораздо больше ресурсов чем он берет на работоспособности компа это не отразится даже если потребление ресурсов увеличится в 2 раза.

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



13 октября 2009, 10:31
Зарегистрирован: 11 июля 2009, 11:46
Забыл написать.

Ползунок прогресса всегда подвисает и до конца процесса не движется.

Работает только если процесс происходит быстро, а при долгих всегда замирает.



14 октября 2009, 07:42
Зарегистрирован: 10 апреля 2012, 00:00
Такая проблема, по моему, только в поиске дублей (медленная скорость).

В остальном скорость, как на меня, вполне сносная.

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

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



14 октября 2009, 08:44
Зарегистрирован: 11 июля 2009, 11:46
В принципе скорость устраивает но только когда делаю один проект, если подготавливать контент под несколько проектов то начинаются тормоза.

1 Сохранение и открытие больших проектов происходит медленно.

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

3 Поиск дублей статей. Для крупного проекта в 3000-и больше функция становится практически не применимой так как требует очень много времени, несколько часов.

4 Импорт отдельных файлов со структурой папок происходит немного медленно когда фалов 10-30к хотя тут можно подождать но всё же.

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

Вот как то так.

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



14 октября 2009, 09:08
Зарегистрирован: 10 апреля 2012, 00:00
Забыл сказать, открытие и сохранение нельзя делать много поточными, там работа с файлами. Но оптимизировать можно попробовать (правда скорее всего в ущерб свободного места на диске :))

По поводу фоновости, то не получится: нельзя проверять какие-то данные и одновременно давать доступ на их редактирование, в таком случае придётся ввести кучу проверок и всё это делать на лету. Одним словом производительность упадёт, а шанс получить ошибку значительно вырастет

По поводу загрузки списка папок и файлов - все претензии в майкрософт :roll:



14 октября 2009, 09:51
Зарегистрирован: 11 июля 2009, 11:46
Забыл сказать, открытие и сохранение нельзя делать много поточными, там работа с файлами. Но оптимизировать можно попробовать (правда скорее всего в ущерб свободного места на диске :))


Места на нынешних винтах полно, +- 2-5Gb думаю даже будет и не заметно :D Так что думаю если это возможно то выжать по максимуму по скорости.

По поводу фоновости, то не получится: нельзя проверять какие-то данные и одновременно давать доступ на их редактирование, в таком случае придётся ввести кучу проверок и всё это делать на лету. Одним словом производительность упадёт, а шанс получить ошибку значительно вырастет


Я так и думал, просто предложил вариант который на уме вертелся.

А каким образом сейчас происходит выявление дубей статей? Можно вкратце описать его.

По поводу загрузки списка папок и файлов - все претензии в майкрософт :roll:


Вот они гады :lol:

А если серьезно, то может быть можно немного сэкономить в тот момент когда происходит вырезка тегов?



14 октября 2009, 10:49
Зарегистрирован: 10 апреля 2012, 00:00


А каким образом сейчас происходит выявление дубей статей? Можно вкратце описать его.


Каждая статья сравнивается с каждой (исключая пробелы). Т.е. на наличие почти полного соответсвия.

А если серьезно, то может быть можно немного сэкономить в тот момент когда происходит вырезка тегов?


Имеется ввиду очистка вордовского мусора? Если да, то там итак процесс почти мгновенный. Медленно импортируются doc файлы, так как их сначала нужно перевести в html (тут тоже особо ничего не поделаешь), а всё остальное быстро.



16 октября 2009, 05:33
Зарегистрирован: 25 июля 2009, 11:00
Забыл написать.

Ползунок прогресса всегда подвисает и до конца процесса не движется.

Работает только если процесс происходит быстро, а при долгих всегда замирает.


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

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

Особенно когда импортируешь больше 1000 постов+разбивка+метки+автокатегории+автодата и т.д.