[Pcrepair]

Добрый день. Есть следующая ситуация :
- программа по УРЛ загружает множество картинок с сайтов записывает их в указанный каталог на ЖД под своими собственными именами. все очень наглядно, можно просмотреть, если нужно, картинки
- на текущем этапе уже не нужно просматривать картинки, и значит не нужно записывать их на ЖД. лучше сразу в ГлобПерем.

Вопрос : какого типа нужно использовать переменную, учитывая что :
- файлы графические(бинарные?)
- размер файла от 1 до 1000 кб
- число файлов - тысячи
- общий объем загрузки может состовлять ?сотни мегабайт
- желательно чтобы метод был универсальный(веб-страницы то же чтоб можно было сохранять)
- не было потенциальной возможности сбоя(из за типа переменной) при хранении данных в ОЗУ

[NumLock]

Хранить файлы в переменных невозможно. Переменная хранит обычно от 1 до 4 байт.

[Pcrepair]

TStringList ну пускай объект-класс. не надо придираться по мелочам

[NumLock]

А почему не TList<TJPEGImage> ?

[Alegun]

Сообщение от Pcrepair

...на текущем этапе уже не нужно просматривать картинки, и значит не нужно записывать их на ЖД. лучше сразу в ГлобПерем...

Но скачивать картинки по ссылке всёравно придётся, ведь что смотреть, что в "ГлобПерем" заносить, нужен набор байтов для этого. А можно сделать так

Код:

uses UrlMon;
procedure TForm1.Button1Click(Sender: TObject);
var
 URLfile, Fname: string;
begin
 // "УРЛ...картинки"
 URLfile:= 'http://kaifolog.ru/uploads/posts/2011-10/1319535258_002.jpg';

 // "указанный каталог"
 Fname:= ExtractFilePath(ParamStr(0)) +

         // "под своими собственными именами"
         Copy(URLfile,LastDelimiter('/',URLfile)+1,Length(URLfile));

 // "можно просмотреть...картинки" если уже есть на диске
 if FileExists(Fname) then Image1.Picture.LoadFromFile(Fname)
   else

    // или "записывает их в указанный каталог на ЖД"
    UrlDownloadToFile(nil,PAnsiChar(URLfile),PAnsiChar(Fname),0,nil);
end;

[Pcrepair]

Alegun, спасибо за внимание, но

- программа по УРЛ загружает множество картинок с сайтов записывает их в указанный каталог на ЖД под своими собственными именами. все очень наглядно, можно просмотреть, если нужно, картинки

это уже сделано, давно, работает

еще раз, прям сейчас :
- многопоточные загрузчики, под управление диспетчера потоков, грузят в указанный каталог на ЖД графические файлы разных типов и размеров
- по окончании загрузки имена файлов записываются в список ТСтрингЛист
- в цикле ДЛЯ файлы вызываются по имени и анализируются по указанным параметрам (размер файла, тип файла, ширина-высота файла) и ИМЕНА файлов сортируются в списке по правилам
- файл с первым именем в списке(с самым большим индексом) вызывается, обрабатывается и сохраняется в другом каталоге с другим именем
- в первом каталоге все файлы удаляются
Следующий цикл загрузки картинок, и так тыщи циклов

мне не нравится первый пункт, запись файлов на ЖД. оно совершенно не нужно. вопрос в какой потомок ТСтрингс(или куда еще) и как записать множество самых разных типов файлов. но только не надо догадки тут постить. если нет реального опыта, писать не надо.

[icWasya]

Например, сохранять не в файл, а в TMemoryStream. Только тип файла надо хранить где-нибудь в другом месте.

[Alegun]

Сообщение от Pcrepair

...вопрос в какой потомок ТСтрингс(или куда еще) и как записать множество самых разных типов файлов. но только не надо догадки тут постить. если нет реального опыта, писать не надо.

В ТСтрингс без прикручивания TObject файлы записать нельзя, формат немного не тот у носителя, тексту - текстово. Догадки пошли, они и не нужны, сами файлы, только инфа "размер файла, тип файла, ширина-высота файла". Без догадок, у меня анализатор капчи вбирает картинки посредством апишной функции URLOpenBlockingStream() в массив типа array of IStream, после конвертации TOLEStream > TMemoryStream откуда нормально грузятся в битмап пикчи имиджа через .LoadFromStream(), но есть ещё URLOpenStream и URLOpenPullStream

[lmikle]

Ну а классы и дженерики тебе нафига даны.

Код:

interface 

type
  TMemDataType = (mdtJpeg, mdtHtml);

  TMemData = class
  private
    FDataType : TMemDataType;
    FData : TStream;
  public
    constructor Create(ADataType : TDataType; AData : TStream);
    property DataType : TDataType read FDataType;
    property Data : TStream read FData;
  end;

  // Если нужно что-то специфичное, то "рожаем" наследников
  TJpegMemData = class(TMemData)
  private
    FWidth : Integer;
    FHeight : Integer;
  public
    constructor Create(AData : TStream; AWidth, AHeight : Integer);
    property Width : Integer read FWidth;
    property Height : Integer read FHeight;
  end;

// А тут список для хранения всего этого счастья
var
  LoadedData : TObjectList<TMemData>;

implementation
  
constructor TMemData.Create(ADataType : TDataType; AData : TStream);
begin
  inherited;
  FDataType := ADataType;
  FData := AData;
end;

constructor TJpegMemData.Create(AData : TStream; AWidth, AHeight : Integer);
begin
  inherited Create(mdtJpeg,AData);
  FWidth := AWidth;
  FHeight := AHeight;
end;

// Создание и удаление глобального списка
initialization
  LoadedData := TObjectList<TMemData>.Create;

finallization
  FreeAndNil(LoadedData);

end.

Как то так.
Только не забыть при работе со списком обеспечить потокозащищенность.

ЗЫ. А вообще зачем хранить все в памяти, если потом идет обработка и удаление лишнего и сохранение только полезного. Может проще просто прямо в потоке проанализировать и не сохранять ничего лишнего?

[Pcrepair]

ЗЫ. А вообще зачем хранить все в памяти, если потом идет обработка и удаление лишнего и сохранение только полезного. Может проще просто прямо в потоке проанализировать и не сохранять ничего лишнего?

Наверно потому что загрузка картинок многопоточная и ассинхронная. вначале нужно загрузить ВСЕ картинки и только потом их анализировать. вот именно для этого их нужно где то хранить. пока на ЖД. но чтобы не пилить ЖД(и ССД тоже не любят лишние циклы записи) и нужно НАКАПЛИВАТЬ граф.файлы в ОЗУ.

ну теперь то уже все понятно?

[M.A.D.M.A.N.]

Вариант №1 — колхозный: создать RAM-диск и в него сохранять
Вариант №2 — близкий к решению: картинки сохранять в TMemoryStream, оттуда же и обрабатывать их.

Оба варианта не защищены от сбоев (типа потеря электропитания).

Вариант №3 — компромиссный: анализировать картинки по мере загрузки, если картинка удовлетворяет каким-либо условиям — сохранять её на hdd.

[lmikle]

Сообщение от Pcrepair

ну теперь то уже все понятно?

непонял... это что, наезд? чем-то недоволен?

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

[Bargest]

- в цикле ДЛЯ файлы вызываются по имени и анализируются по указанным параметрам (размер файла, тип файла, ширина-высота файла) и ИМЕНА файлов сортируются в списке по правилам
- файл с первым именем в списке(с самым большим индексом) вызывается, обрабатывается и сохраняется в другом каталоге с другим именем

Следовательно, все файлы тебе не нужны, нужен только один по совокупности признаков. Признаками не является весь файл.
Сортировка всегда основывается на сравнении двух элементов по набору признаков, значит эта функция сравнения у тебя есть. Назовем её "условием F".
Поэтому:
0) Делаешь переменную с одной (первой попавшейся) картинкой в памяти. Называем её "текущей". Сохраняешь в переменных её параметры.
1) Скачиваешь очередную картинку.
2) Вытаскиваешь нужные тебе признаки.
3) Проверяешь условие F для скачанной картинки и для текущей. Если по этим признакам скачанная картинка должна оказаться при сортировке до текущей - в переменную текущей картинки сохраняешь скачанную и меняешь переменные с параметрами.
В противном случае выбрасываешь скачанную, т.к. она в любом случае не окажется первой при сортировке (ведь текущая до неё).
4) Если есть что еще качать - вернуться к п.1.

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

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