Невозможна Отмена процесса в Зеброиде

Давно заметил, что на многих процессах (когда идет процент выполнения работы) не работает кнопка "Отмена". Она там для красоты? Уже несколько раз приходилось убивать Зеброид через диспетчер задач, т.к. кнопки отмена Зеброид упорно отказывается слушаться и продолжает процесс, который порой будет идти часами или десятками часов. Из-за этого теряются несохраненные данные в проекте. В частности, речь веду об очень важном окне "Чистка заголовков и статей".

PS Есть ли в планах Зеброид x64? 32-битная версия ни в какую не переваривает даже каких-то 100 тыс статей? Съедает всего 1.8Гб памяти и умирает с бесконечной ошибкой, типа, Out of memory.

Ладно уже 3.44 утра отписываюсь как экспортировал с Вашей снятой галочкой: ушло на 104000 картинок, да все картинки это аватарки + 7761 статьи 26 минут это просто застрелиться!!! Когда все экспортировалось загнал в Textkit ну и естественно стал делать тесты и "Охренел" от "тормазнутости" Вашей программы, блин причем "Тормазнутости" с Большой буквы....

Значится так, тот же самый проект загнанный в Textkit причем я делал не просто в текстовые файлы а экспортировал в Wordpess на все про все ушло 6 минут да, на текстовые файлы, мнеж все-таки стало интересно Textkit потратил 20 секунд!!!

Дальше вообще интереснее. Открываю тот-же самый проект зеброидом и делаю изменение в статье "Ну мало ли иногда бывает нужно" и нажимаю кнопку сохранить " еще раз повторяю со снятой галочкой" "АХРЕНЕТЬ" молниеносная реакция программы которая длится 26 минут "всеголиш-навсего"

и проект сохранен. У ТОГО ЖЕ Textkit НА ЭТО УХОДИТ 1"СЕКУНДА" на том же самом проекте. ДА, ЭТО ПО ПОВОДУ "КТО КУРИТ".

Так вот уважаемый разработчик обижайтесь или не обижайтесь но программа работает не к черту с большими файлами если конечно 7000 страниц можно назвать "Большим проектом" а то тут тема началась со 100 тысяч страниц которые "В чем я даже не сомневаюсь" Ваш зеброид не когда не обработает а если и обработает то это будет не в нашем тысячелетии да и уже не и так актуально.

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

Да я конечно понимаю что критиковать легче всего но мне от этого легче не становится.

Лично я порубил проект на куски. Вот 17613 статей, кусок первый. Поиск дублей начал в 17 вечера вчера, комп работал всю ночь, сегодня утром закончил. Загрузка проца около 23%, проц i5 3200Мгц, память 8Гб. За неделю дубли обработаю, потом остальное опять кусками, а что делать? В ТекстКит проект аналогично завис на неизвестно какое время, даже не стал дожидаться. Программы не умеют забирать память, не умеют нагружать ядра, они морально отстают на лет 10 от возможностей компов. На сегодняшний день, программ для работы с большими проектами не существует! Все равно я хочу сказать разработчику спасибо, потому что если бы не Зеброид, руками это переварить вообще нереально. ТекстКит еще опробую на кусках, но там конечно настройки поиска дублей - 3 галки (вкл и выкл)!

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

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

Если вы хотите, чтобы ситуация поменялась, то помогайте мне, а не обливайте всё и вся гразью. Что мне действительно поможет - так это ваш проект и описание всех замеченных вами проблемных мест. С того, что я понял из предыдущего сообщения, что скорость экспорта и сохранения проекта вас не удовлетворяет, это всё?

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

Для сравнения сегодня в 11.00 запустил 12Мб-кусок проекта в Зеброиде и в 11.30 16Мб-кусок ТекстКит. Обработка такая: поиск и удаление дубликатов статей по названию и тексту статьи, без лемматизации, уникальность 95%, переместить дубли в папку "дубли", у ТекстКит - включены обе галки (поиск по заголовкам и статьям), кроме "текст ИЛИ статьи". В 16.00 (или раньше) ТекстКит успешно справился, а Зеброид показал 66%.

Про настройку ядер не знал, как закончит Зеброид работу, протестирую обязательно!

По поводу эмоций admin, несомненно, прав.

Для сравнения сегодня в 11.00 запустил 12Мб-кусок проекта в Зеброиде и в 11.30 16Мб-кусок ТекстКит. Обработка такая: поиск и удаление дубликатов статей по названию и тексту статьи, без лемматизации, уникальность 95%, переместить дубли в папку "дубли", у ТекстКит - включены обе галки (поиск по заголовкам и статьям), кроме "текст ИЛИ статьи". В 16.00 (или раньше) ТекстКит успешно справился, а Зеброид показал 66%.

Про настройку ядер не знал, как закончит Зеброид работу, протестирую обязательно!

По поводу эмоций admin, несомненно, прав.

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

Огромное спасибо за подсказку с ядрами! Признаюсь, давно не заглядывал в настройки программы. Загрузка ЦП пошла 95-97, память %zebroid3 302 MB. Аж приятнее, что времени уйдет в 4 раза меньше. А то у меня уже была идея использовать Зеброид+ТекстКит для обновременной обработки разных кусков, чтоб нагрузить ЦП хотя бы на 50%.

С экспортом лично у меня проблем никаких нет. Кусок в 6-7 тыс статей экспортируется 1-2 сек. Может, потому что не содержит картинок совсем. Претензий к качеству работы системы поиска дублей тоже не имею. Впрочем, и ТекстКит справился корректно.

Что касается экспорта и сохранения проектов с большим количеством картинок (то, на что жалуется [user:1r06q8jv]lapa666[/user:1r06q8jv]) - работы в этом направлении ведутся, надеюсь в четвертой версии программы удаться сделать максимально быструю обработку.