Ускорение работы программы в 2-6 раз. Многопоточность.

Заметил странность, или недочет. У меня при включенной настройке «3 ядра процессора». Работает 1 ядро. Думаю из за этого все проблемы:



1. Открытие проекта 35к записей, — 10 секунд. А открытие проекта 100к записей ~5 минут (в 6 раз медленнее, почему так?)
2. Рандомное выделение записей в проекте, где 100к записей ~ 5 минут.
3. Инвертирование рандомно-выделенных записей ~ 10 минут.
4. Удаление рандомно выбранных записей 35% из 100к ~ 5 минут.
5. Запустил плагин TitleAdder подключил файл с 70к строками, по подсчетам придется жать 75 минут.
При всем этом работает одно ядро.

Почему не в ошибки добавили?

p.s. Не понимаю людей, которые создают темы и сами за них не голосуют. Если вы хотите реализацию этой идеи — то необходимо проголосовать за неё. Если это не ошибка в программе.

b2b в своем сообщении писал(а):Почему не в ошибки добавили?
p.s. Не понимаю людей, которые создают темы и сами за них не голосуют. Если вы хотите реализацию этой идеи — то необходимо проголосовать за неё. Если это не ошибка в программе.

Баллы я потратил на свое предыдущее предложение. Спасибо разработчику, ускорил расстановку комментариев, вместо 13 часов ожидания — теперь 20-30 минут. Вот и тут такое.

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

Перенес тему в Вопросы, сразу объясняю почему: не все операции можно распаралелить. Если конкретно по вашему примеру, то…

1. Открытие проекта нельзя разнести в разные потоки, потому что самые трудоемкие операции в этом случае — это чтение файла и добавления данных в массив. Массив записей один, с ним нельзя одновременно работать с нескольких потоков. С файлом примерно та же фигня. Что касается «в 6 раз медленнее, почему так?» — потому что в данном случае есть геометрическая прогрессия, а не арифметическая. Это примерно если вы написали: я пробегаю 100 метров за 15 сек, а 100 км. за неделю. Программа конечно не знает усталости, но чем больше массив данных, тем дольше процесс добавления в него новых ячеек.

2. И опять таки нельзя в несколько потоков, иначе в результате вы можете получить отмеченными все записи или ни одной

3. Теоретически можно было бы, практически в Delphi (на котором написана программа) нельзя работать с визуальными компонентами не из основного потока

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

5. Библиотека для работы с пхп сервером из программы не предусматривает многопоточности. Но вам бы я рекомендовал использовать встроенный инструмент «Подмешивание ключевых слов», который работает многопоточно и с недавнего времени умеет работать с заголовками.

Так же стоит заметить, что многопоточность не даёт пропорциональных увеличений скорости. Если вы используете 3 ядра, а переключите на одно — то программа будет работать примерно в 1,5-2,5 раза быстрее (зависит от операций), но никогда не в 3. Что касается этого:

Спасибо разработчику, ускорил расстановку комментариев, вместо 13 часов ожидания — теперь 20-30 минут.

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