Оптимизация потока

[Ghost of Night]

Здравствуйте, имеется поток, который шифрует файл. можно ли как-то оптимизировать работу с файлами в этом потоке?

[Ghost of Night]

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

[Человек_Борща]

Меня больше интересует как выполнять операции с файлом, не копируя его во временные переменные?

Это смотря как задавать вопрос.
Ну допустим:
I. Ты берёшь n байт файла, изменяешь их и записываешь обратно. Эта операция потребует много ресурсов от системы.
Тут 6 действий:
1. Получаем размер файла байтах
2. Получаем n байт файла от начала файла
3. Изменяем байты файла
4. Записываем изменённые байты, обратно в файл(Опущу проверку на корректность файла(Байтики-то и сместиться могут))
5. запоминаем где читали и куда писали
6. Повторяем все выше перечисленно пака байты не закончаться.
Минусы:
1. Старый файл будет 100% перезаписан без каких-либо выкрутасов.
2. Нужно следить за тем чтобы файл никто не трогал, пака с ним работает поток. 1 сдвиг, и весь процесс на смарку.
3. Если процесс оборвётся , изменения обратить будет очень сложно. Файл будет испорчен.


II. Можно закачать в поток весь файл и быстро его обработать.
Тут тоже 3 действия, но выполняются они один раз:
1. загружаем файл в поток
2. меняем байты
3. Сохраняем файл обратно(перезаписав старый или сохранив новый в другом месте), и это +
Нежели перекать его 100500 раз в память по байтно.


Так что лучше чем поток(Stream) врятли что-то предумаешь.
Безопаснее, удобнее и 100% гарантия что оригинал не будет испорчен.

Что касается оптимизации.
1. Нигде ни разу не видел Try..finally..end;
Стуация:
Пользователь повесил программу(Повиг каким образом), и ОЗУ ПК быстро исчезнет пака поток не отработает(Ну или пака он будет закрываться).
2. Вместо TObject.Free используй FreeAndNil(TObject);
3. Нигде нет ни намёка на проверку Terminated флага.

Шифрование(ну или что у тебя там), можно разрезать на потоки.
просто разбив файл по потокам и раздав по кусочку в каждый TStream для каждого потока.
берётся файл, его размер в байтах и по цепочке потоки откусывают n байт файла передав след. потоку указатель на место, до которого откусил предыдущий поток, и так до того момента пака байты не закончаться.
Склеивание происходит также, первый поток уведомляет о завершении процесса и передаёт указатель на место, к которому нужно присоеденять байты.

Тут есть и минусы и плюсы.
Плюс в том что все это будет работать в хреналион раз быстрее.
Но нужно чтобы потоки что-то контролировало. Особенно очередь разделения файлов и очередь склеивания. Ведь закончить перым, может и пятый и десятый, а надо с 1 начинать и 10 заканчивать=)

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

Собственно минус это установить жосткий контроль над процессом дробления файла между потоками, и сборкой этого файла в правильном порядке.

В общем читай о синхронизации потоков.

Но ту просто, 1 поток просто контиролирует в кком порядке файл был разобран, и составляет список дескрипторов потоков которые уже закончили обработку, сортирует их и выстраивает правильную очередь для сборки. Затем подаёт команды по одному.

Че-то меня попёрло...
Все, я спать

Ту

[Ghost of Night]

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

1.файл грузится в TStream пусть это будет f
2.поток шифруется блоками и записывается в другой TStream(buf).
3.поле этого f заменяется на buf и передается другому алгоритму.
4.buf очищается и шаги 2-3 повторяются.
5.сохраняем результат в файл.

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

p.s. файл в 800кб у меня обрабатывается 4-мя алгоритмами ~5-15 мин. точно не замерял. А файл размером 150мб вешает этот поток.м

Кстати, по поводу try..except, спасибо учту, это только пока "скелет" программы, а проверки навешивать я буду позже.

[Человек_Борща]

ну шаг с переходом f=>Buffer можно выкинуть у потоков есть метод CopyStream копрует данные одного потока, в другой.

Почитай тов справке.

[Ghost of Night]

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

[Человек_Борща]

А про это читал?

Сообщение от Delphi HELP

Copies a specified number of bytes from one stream to another.

Delphi syntax:

function CopyFrom(Source: TStream; Count: Int64): Int64;

C++ syntax:

__int64 __fastcall CopyFrom(TStream* Source, __int64 Count);

Description

Use CopyFrom to copy data to the stream from a different stream. Using CopyFrom eliminates the need for the user to create, read into, write from, and free a buffer when copying data.

CopyFrom copies Count bytes from the stream specified by Source into the stream. It then moves the current position by Count bytes, and returns the number of bytes copied.

If Count is 0, CopyFrom sets Source position to 0 before reading and then copies the entire contents of Source into the stream. If Count is greater than or less than 0, CopyFrom reads from the current position in Source.

[Ghost of Night]

Т.е. без дополнительной переменной не обойтись?. Можно только убрать её инициализацию и освобождение. да?

[Человек_Борща]

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

Инициализци и финализация должны быть, если это не массив байт.

[Ghost of Night]

Получается мой вариант (в архиве) менять не нужно? я имею ввиду копирование из одной переменной в другую