Господа посоветуйте как максимально ускорить следующий процесс (на данный момент простой цикл, сборка списка файлов, потом обработка по списку): есть энное количество текстовых файлов (может и тысяча быть, а может и всего десяток), мне нужно их открыть (сейчас читаю в tstringlist), далее выполнить операции (замены, удаления), после сохранить файл.
Уместно ли использование потоков для ускорения процесса обработки? Уменьшит ли это время обработки? Что еще можно сделать для ощутимомго ускорения операций. При работе со строками (замены, удаления)  использую функции из QStrings.

Это сообщение отредактировал(а) alexpotemkin - 9.9.2008, 13:20

Ты бы не описал принцип работы, а код показал. А мы тебе его бы "ускорили"  На вскидку, поток с завышенным приорететом в любом случае будет быстрее   

дабы не приводить весь код, примерно так все выглядит (обрежу для упрощения, обработчиков исключительных ситуаций тоже обрежу):




Это сообщение отредактировал(а) alexpotemkin - 9.9.2008, 14:21

Грамотное использование потоков ускоряет работу, если разделить по потокам загрузку из файла и текстовую обработку. Т.е. полезным будет создание еще 2х потоков. 

Алексис, а можно чуть подробней?

alexpotemkin, конкретно по приведенному коду:

• list.Clear ни к чему там. Там заведомо известно что list чиста
• я бы отказался от переменной txt
  

  Код

  list.Text:= QReplace_Str(list.Text, 'шыло', 'мыло');

• Alexeis дело говорит  В то время пока один поток загружал бы список файлов, второй (или вторые) мог бы уже эти файлы обрабатывать. Так же можно весь список файлов разбить, допустим, пополам и уже двумя потоками обрабатывать одновременно.

txt вводил только ради ускорения работы с переменной, т.к. думал что обращение к переменной по определению будет быстрей чем обращение к list.Text.
По поводу рекомендаций: т.е. мне стоит в одном потоке собрать список, далее этот список разделить на двое и двумя потоками обработать замены. Правильно понял?
Напомните линку на стутью по поводу потоков, здесь была, не могу найти.

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



http://forum.vingrad.ru/forum/topic-60076.html

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

А как захочешь. Можешь - четные одному потоку, не четные - другому. Можешь - первые 100 одному, следующие 100 второму, следующие 100 третьему, следующие 100 опять первому и т.п. Тут уже решать тебе. Идея в том, что бы обрабатывающие потоки работали одновременно.

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

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

С алгоритмом:

Уверены, что здесь нет утечки?

Далее:

Зачем вы гоняете данные из списка в переменную и обратно? Выбросите список, грузите сразу в txt, а ещё лучше - используйте проекции файлов. Правда, в последнем случае вам понадобятся ещё и соответствующие варианты функций QReplace_Str, которые вместо String на вход принимают указатель + размер. Но если ваши искомые и заменяемые строки не соответствуют друг другу по длине, то от проекции придётся отказаться.

CodeMonkey, прав тут оптимизировать и оптимизировать. Нужно заменять построчно, чтобы не гонять большие куски данных в памяти. Операция  txt := list.Text;  и list.Text := txt; занимает огромную кучу времени, а txt := QReplace_Str(txt,'шыло','мыло');  еще больше.

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

Я бы вообще выкинула все list`ы к чертовой бабушке и работала с файлом как с цельным блоком данных.   
Конечно придется повозиться, но
1. В этом нет ничего сложного - стандартные алгоритмы.
2. Выигрыш в быстродействии реален не в разы а на порядки.

> вообще быстрее всего будет сразу загрузить текст в одну длинную строку,
Ага
Будет чуть быстрее