Вверх ↑
Этот топик читают: Гость
Разработчик
Ответов: 26163
Рейтинг: 2127
#31: 2015-01-13 13:31:09 ЛС | профиль | цитата
Netspirit, преимущество связанных через проекцию файлов в его низкоуровневости, минуя все системные интерфейсы. Быстродействие проекций всегда будет выше работы через системные интерфейсы. Размером блока проекции можно управлять, что нельзя делать при помощи обычных стримов, там сколько тебе выделила система, столько и жуй.
карма: 22

0
Ответов: 9906
Рейтинг: 351
#32: 2015-01-13 13:35:17 ЛС | профиль | цитата
2Netspirit
Size - integer.
А я предлагаю НЕ ДЕЛАТЬ ничего. Разницу чувствуете
Пока не научились делать так, чтобы не надо было переделывать.

Ну не клюет жаренный петух никуда. Чтобы сопровождать с десяток элементов. После "сделать"...
И не парится никто.
Потому что давно работает все. И мы не обсуждаем способы преодоления проблемы неработающего элемента.
Мы другое обсуждаем.


------------ Дoбавленo в 13.35:
Netspirit писал(а):
Как я понял, в системе суть SharedStream - не работа с большими файлами, а некоторый BufferedFileStream

Неправильно понял
карма: 9

0
Ответов: 4631
Рейтинг: 749
#33: 2015-01-13 13:45:40 ЛС | профиль | цитата
nesco писал(а):
Быстродействие проекций всегда будет выше работы через системные интерфейсы
Вероятно, быстродействие достигается за счет размещения рабочей части в памяти. То-есть, buffered file stream.
Galkov писал(а):
Мы другое обсуждаем
Если обсуждаем упрощение компонента SharedStream, чтобы всем было понятно его использование, тогда согласен
Galkov писал(а):
НЕ ДЕЛАТЬ ничего
Я предлагаю исключительно варианты решения проблемы больших файлов. Настаивать не собираюсь.
карма: 26

0
Ответов: 9906
Рейтинг: 351
#34: 2015-01-13 13:53:29 ЛС | профиль | цитата
nesco писал(а):
А вот количество выделяемых страниц памяти я не стал бы убирать, от этого очень сильно зависит быстродействие всего процесса

Что бы будешь делать у себя у нутре, и что будет видеть пользователь - две большие разницы.

Пользователь задал удобный ему Offset и Size.
Ты (к примеру!!!) их выравниваешь по гранулярности. Но это твои (пардон - наши) внутренние заморочки, и мы никогда об этом никому не будем рассказывыать. Даже под пытками.
Размэпил - ну прибавь ты нужное число к результирующему поинтеру при установке fMemory, чтобы пользователь получил по нулевому смещению именно тот байт, который хотел.
И размер для стрима - тот, что задал пользователь, а не "гранулированный".
Арифметика же, блин...

А вот "гранулировать" размер можно не всегда...
Даже если это и быстрее.
Если внутри файла - так нет проблем.
Если выходим за размер оригинала, то такие шутки кончаются изменением реального размера реального файла.
Мне кажется, что это неправильно.
------------ Дoбавленo в 13.53:
Де-жа-вю, блин...
Все это я уже говорил когда-то давно
Не ткну
карма: 9

0
Ответов: 4631
Рейтинг: 749
#35: 2015-01-13 13:54:01 ЛС | профиль | цитата
Galkov писал(а):
Неправильно понял

Аргументируй. SharedStream (а точнее, File mapping) - это ... ?
карма: 26

0
Ответов: 9906
Рейтинг: 351
#36: 2015-01-13 13:56:11 ЛС | профиль | цитата
Например: инструмент межпроцессной связи.
Самый низкоуровневый (вся остальная фигня у нутре оси на ем и построена) => самый быстрый.
"у нас это реализовать" - нельзя.
карма: 9

0
Ответов: 4631
Рейтинг: 749
#37: 2015-01-13 14:26:49 ЛС | профиль | цитата
Согласен, что в том числе, для работы нескольких процессов с одними данными.
Ну, а скорость за счет чего достигается? Неужели при работе с обычными файлами система пишет/читает с диска медленнее, чем пишет/читает в том же File mapping? Нет, с диском она работает на той же скорости. Но с той частью, которая в данный момент расположена в памяти - естественно, гораздо быстрее. Данные, ожидающие записи на диск, записываются позже по мере необходимости.
Вся эта кухня скрыта и для пользователя всё выглядит, как работа с памятью. Но, тем не менее, MapViewOfFile грузит необходимую часть файла в память, UnmapViewOfFile (а также FlushViewOfFile и FlushFileBuffers) сбрасывают изменения на диск. И чем это отличается от Buffered File Stream (если не стоит задача расшарить между процессами)?

И при чем тут большие файлы...
------------ Дoбавленo в 14.26:
Вот чисто из любопытства. Есть схемка

Add(MainForm,2953706,21,105)
{
Height=228
Caption="File copy test"
Position=1
}
Add(Label,1543935,21,168)
{
Left=10
Top=20
Width=87
Height=17
Caption="Исходный файл:"
}
Add(Edit,1702965,217,168)
{
Left=100
Top=15
Width=200
Text=""
}
Add(Button,15719336,105,168)
{
Left=315
Top=15
Width=65
Caption="Обзор"
link(onClick,1096610:doExecute,[])
}
Add(ODialog,1096610,161,168)
{
Filter="Все файлы (*.*)|*.*"
Title="Выбор файла"
FileName=""
Point(FileName)
link(onExecute,1702965:doText,[])
link(FileName,2281709:getVar,[])
}
Add(SDialog,15836243,161,287)
{
Filter="Все файлы (*.*)|*.*"
Title="Сохранение"
FileName=""
Point(FileName)
link(onExecute,9413449:doText,[])
link(FileName,8759727:getVar,[])
}
Add(LineBreakEx,2281709,161,133)
{
Caption="src"
Type=2
}
Add(LineBreakEx,5137826,217,217)
{
Caption="src"
Type=3
link(_Data,1702965:Text,[])
}
Add(LineBreakEx,8759727,161,252)
{
Caption="dst"
Type=2
}
Add(LineBreakEx,4250756,217,336)
{
Caption="dst"
Type=3
link(_Data,9413449:Text,[])
}
Add(Label,9405329,21,287)
{
Left=10
Top=65
Width=86
Height=17
Caption="Конечный файл:"
}
Add(Edit,9413449,217,287)
{
Left=100
Top=60
Width=200
Text=""
}
Add(Button,3039266,98,287)
{
Left=315
Top=60
Width=65
Caption="Обзор"
link(onClick,15836243:doExecute,[])
}
Add(Button,1685428,56,546)
{
Left=105
Top=115
Width=180
Height=50
Caption="Копировать!"
link(onClick,11999779:doStart,[])
}
Add(LineBreakEx,16559159,343,399)
{
Caption="src"
Type=2
}
Add(LineBreakEx,14989227,434,399)
{
Caption="dst"
Type=2
}
Add(Message,4414827,616,476)
{
Caption="Результат"
}
Add(FormatStr,2501378,560,476)
{
DataCount=1
Mask="Копирование завершено!
Скопировано %1 байт."
link(onFString,4414827:doMessage,[])
}
Add(TimeCounter,11999779,161,546)
{
link(onStart,5224921:doEvent1,[(209,552)(209,454)])
link(onStop,15347917:doStrCat,[])
}
Add(LineBreak,14808041,105,553)
{
Caption="stop"
link(Out,11999779:doStop,[])
Primary=[15464532,455,-105]
}
Add(Hub,622976,518,448)
{
link(onEvent1,15464532:In,[])
link(onEvent2,2501378:doString,[(546,461)(546,482)])
}
Add(Label,2082802,287,553)
{
Left=175
Top=175
Width=40
Height=17
Caption="Время:"
}
Add(StrCat,15347917,224,553)
{
Str1="Время: "
link(onStrCat,2082802:doText,[])
}
Add(Hub,5224921,245,448)
{
}
Add(SharedStream,12902902,385,455)
{
}
Замутите мне копирование файла, размером так около 3Гб, с помощью SharedStream, чтобы можно было удостовериться в скорости.
карма: 26

0
Ответов: 9906
Рейтинг: 351
#38: 2015-01-13 14:46:51 ЛС | профиль | цитата
Netspirit писал(а):
И при чем тут большие файлы...

Не причем.
Они просто есть, как бесплатное приложение.
Но - они ЕСТЬ, даже если ничего не делать.
И если придет чел, и скажет: "нет жизни без умения читать содержимого видеоперехвата" -- ему можно ответить: "НА"
Я пока помню только один такой случай.
Это проще, чем: "можно сделать ТО", "можно сделать ЭТО"...

Netspirit писал(а):
Ну, а скорость за счет чего достигается?

Ну например, за счет того, что для межпроцессного обмена файлы вообще не нужны.
Пустое имя (точнее, -1 в качестве хэндла файла) - и все работает.
Это не мы так придумали, а мягкотелые.

Netspirit писал(а):
чтобы можно было удостовериться в скорости.

Ну причем тут за рыбу деньги...
Какое winApi не применяй - винт быстрее крутиться не станет.
Под "быстрее" понималось вот это:
nesco писал(а):
Быстродействие проекций всегда будет выше работы через системные интерфейсы.
Потому что эти "системные интерфейсы" и используют проекции для своей работы (связь между процессами).
Как бы самоочевидное утверждение (без проверок), если принять за правду предыдущее предложение.

А это мы с nesco не сами придумали, а прочитали у Рихтера.


карма: 9

0
Ответов: 4631
Рейтинг: 749
#39: 2015-01-13 14:58:03 ЛС | профиль | цитата
А это не я придумал:
nesco писал(а):
я еще раз повторюсь, что для копирования файлов такой длины кроме SharedStream лучше ничего не использовать. SharedStream использует API низкоуровневого копирования, быстрее которого не копирует уже ничего

карма: 26

0
Разработчик
Ответов: 26163
Рейтинг: 2127
#40: 2015-01-13 15:21:29 ЛС | профиль | цитата
Netspirit писал(а):
Замутите мне копирование файла

В справке есть пример копирования, можешь протестировать, там даже время копирования измеряется. Размером количества страниц можно отрегулировать нужное быстродействие, по дефолту буфер около 10 Мб
карма: 22

0
Ответов: 4631
Рейтинг: 749
#41: 2015-01-13 15:53:09 ЛС | профиль | цитата
Проверил, действительно копирует значительно быстрее.
[offtop]В примере из справки если не закрывая программу выполнить копирование повторно, конечный файл получается 0-го размера[/offtop]
карма: 26

0
Разработчик
Ответов: 26163
Рейтинг: 2127
#42: 2015-01-13 16:48:10 ЛС | профиль | цитата
Netspirit писал(а):
В примере из справки если не закрывая программу выполнить копирование повторно, конечный файл получается 0-го размера

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

0
Ответов: 4631
Рейтинг: 749
#43: 2015-01-13 16:52:02 ЛС | профиль | цитата
Может это у меня что-нибудь, позже посмотрю.
карма: 26

0
Разработчик
Ответов: 4698
Рейтинг: 426
#44: 2015-01-14 00:18:23 ЛС | профиль | цитата
Galkov писал(а):
Ты же говоришь, что слово "окно" недоступно для твоего понимания, и предлагаешь "продвинутую технологию" в которой уже не меньше двух элементов.
И которая обладает своими ограничениями.

Мне то прекрасно понятно, что такое окно, а "продвинутая технология" - это именно IPC, а не работа с огромными файлами (я изначально не учитывал у себя такой вариант использования). Мы с тобой просто предлагаем решения немного разных задач.
Galkov писал(а):
Кстати, сколько типов "переменных" ты предлагаешь ???
На каждый тип своего клиента делать ???
А если размер типа заранее неизвестен (типа dtAnsiString) ???
И наконец, кто сказал, что файл состоит из каких-то "переменных", прости господи...

Пользователь ничего не будет знать о типе, как это сделано и в обычном штатном Memory. Для пользователя будет "я делаю doSet у SharedMemory и затем могу в другом приложении из такого же SharedMemory получить записанное значение".
А вот к задаче реализации расшаренных именно переменных (а не куска памяти ограниченного размера) как раз и придется подойти инженерно. Нужно ведь обыграть создание именованного ассоциативного массива, расшаренного между приложениями с использованием стандартного FileMapping из WinAPI.
Это довольно сложно, поэтому оно останется мечтами. Но почему помечтать-то уж нельзя?

карма: 10
0
Разработчик
Ответов: 26163
Рейтинг: 2127
#45: 2015-01-14 00:42:56 ЛС | профиль | цитата
Assasin писал(а):
А вот к задаче реализации расшаренных именно переменных (а не куска памяти ограниченного размера) как раз и придется подойти инженерно

Нафиг еще че-то городить, когда и сейчас работает, как обычный, но межпроцессный стрим, а из него можно читать все, чего угодно
карма: 22

0
Сообщение
...
Прикрепленные файлы
(файлы не залиты)