forum.clarionlife.net

kreator писал(а): А было бы интересно.

Честно сказать, не понимаю в чём интерес любого файла в памяти.
Что, консольное приложение выдаёт информацию на несколько мегов?

Может в эту сторону посмотреть?
http://forum.codecall.net/topic/72472-e ... ts-output/

Губин Игорь писал(а):Честно сказать, не понимаю в чём интерес любого файла в памяти.

Я имел ввиду интерес к возможности компилить сишные тексты из VS прямо в Кларионе. И подключать эти все дела к своим проектам. Есть же много open source проектов на C или С++.

kreator писал(а): Я имел ввиду интерес к возможности компилить сишные тексты из VS прямо в Кларионе. И подключать эти все дела к своим проектам. Есть же много open source проектов на C или С++.

Ну, перетаскивать проекты из VS, на мой взгляд, совсем
А вот деланье в VS и подключение дальше DLL не подойдёт?

Губин Игорь писал(а): Честно сказать, не понимаю в чём интерес любого файла в памяти.Что, консольное приложение выдаёт информацию на несколько мегов?

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

Для этого есть каталог временных файлов, пиши и читай сколько хочешь.
Но вот у меня в базе данных хранится OLE-объект с форматированным текстом, а я хочу в той же программе иметь этот текст, но в формате HTML. Функция экспорта есть, но в файл, потом приходится открывать, читать и парсить. А вот ежели бы файл был в памяти - о, как дивно бы выросла производительность программы
Но скорее всего, хочется в памяти формировать ну очень большой документ HTML/XML или запрос SQL, который хз сколько места займёт. И вот тут с ностальгией вспоминаются библиотеки родных сей.

Итак, какие выводы?
In-memory [CMemFile] файл, как он есть в понимании C++ (не употребляю термина виртуальный файл, поскольку даже здесь https://msdn.microsoft.com/ru-ru/library/tzdxd4x0.aspx он так ни разу не называется).
Ограничения:
- время жизни равно времени работы конкретной программы, его создающей.
- размер ограничен размером RAM, т.е. 1-2-4-8 Гб. К тому же это весьма дорогой ресурс.
- неизбежная потеря содержимого при форс-мажоре.
- сложная коммуникация внутри приложения (передать такой файл из OLE, думается, не представляется возможным).
Исходя из этого, когда же он интересен? Для парсинга -- несомненно, особенно какого-нибудь сложного, многопроходного (типа Диссернета).
А в остальном?

Shur писал(а): Исходя из этого, когда же он интересен? Для парсинга -- несомненно, особенно какого-нибудь сложного, многопроходного (типа Диссернета).
А в остальном?

Он интересен всегда, когда требуется интенсивная обработка данных с необходимостью доступа и контроля по ключАМ.
Я использую IMDD в двух случаях:
1. создание большого объёма промежуточных данных, к которым требуется интенсивный доступ и когда постоянная перестройка QUEUE для доступа по новому ключу неоправданна.
2. Обработка в программе большого объёма статичных (справочных) данных, когда выигрыш по скорости во время работы программы оправдывает затраты на загрузку в память.

Да не, Игорь, про IMDD всё ты правильно пишешь.
Я сейчас писал не про IMDD, а про plain CMemFile, чтобы коллеги оценили целесообразность притягивания этого класса к своим разработкам.

Губин Игорь писал(а):Он интересен всегда, когда требуется интенсивная обработка данных с необходимостью доступа и контроля по ключАМ.
Я использую IMDD в двух случаях:
1. создание большого объёма промежуточных данных, к которым требуется интенсивный доступ и когда постоянная перестройка QUEUE для доступа по новому ключу неоправданна.
2. Обработка в программе большого объёма статичных (справочных) данных, когда выигрыш по скорости во время работы программы оправдывает затраты на загрузку в память.

Речь идёт о БД, я так понимаю? TC'у, определённо, не для этого нужен виртуальный файл.
Что касается БД, то In-Memory - это наше всё. Сейчас SQL вендоры делают эту технологию на дорогих и платных серверах, но в будущем это дело у всех появится. Объёмы данных растут, а быстродействие дисковой подсистемы не поспевает.

Shur писал(а): Я сейчас писал не про IMDD, а про plain CMemFile,

Когда объём временного файла настолько большой, что оправдывает затраты

Табличные переменные типа давно существуют (по крайнем мере в MS SQL). Это и есть размещение таблицы в оперативной памяти. Так что у SQL вендоров давно есть, что предложить.
А вот то, что tempdb сейчас некоторые небедные компании стараются размещать на SSD дисках, это да -- веяние относительно новое.

kreator писал(а):

Губин Игорь писал(а):Он интересен всегда, когда требуется интенсивная обработка данных с необходимостью доступа и контроля по ключАМ.
Я использую IMDD в двух случаях:
1. создание большого объёма промежуточных данных, к которым требуется интенсивный доступ и когда постоянная перестройка QUEUE для доступа по новому ключу неоправданна.
2. Обработка в программе большого объёма статичных (справочных) данных, когда выигрыш по скорости во время работы программы оправдывает затраты на загрузку в память.

Речь идёт о БД, я так понимаю? TC'у, определённо, не для этого нужен виртуальный файл.
Что касается БД, то In-Memory - это наше всё. Сейчас SQL вендоры делают эту технологию на дорогих и платных серверах, но в будущем это дело у всех появится. Объёмы данных растут, а быстродействие дисковой подсистемы не поспевает.

In-Memory, как я понимаю, изначально задумывался для кэширования редко изменяющихся таблиц данных на клиенте в клиент-серверных технологиях... Я, во всяком случае, так и не нашел смысла использовать этот инструмент, хотя выглядит привлекательно.

finsoftrz писал(а): In-Memory, как я понимаю, изначально задумывался для кэширования редко изменяющихся таблиц данных на клиенте в клиент-серверных технологиях... Я, во всяком случае, так и не нашел смысла использовать этот инструмент, хотя выглядит привлекательно.

А в результате это наше всё! Нет ничего удобней для работы с файлом когда требуется скорость и нет необходимости опасаться изменения данных кем-то ещё или резкого закрытия задачи.
Я все свои справочные системы перевёл на работу с IMDD с загрузкой данных в память при запуске приложения. Скорость стала просто бешеная. Плюс когда надо отобрать данные из кучи файлов в один с постоянным скаканьем и перестройкой ключей - формируем всё в IMDD, а потом сбрасываем на диск уже готовый результат.

Игорь, может у тебя задачи такие... У меня и так скорость работы высокая. Мелкие таблицы кэшируются и данные из них дергаются очень быстро, без обращения к диску. А результаты всяких отчетов проще получать в очереди. Под них структуру можно декларировать локально, а не в словаре. Много их разных. Некоторые считают правильным всякие накладные кэшировать в памяти, а затем все проведенные изменения в транзакции писать на диск. Но тут тоже палка о двух концах - пользователи оперативно не видят работу друг друга (по сравнению с построчным сохранением), а при непредвиденных сбоях теряется вся работа с накладной...