The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Выпуск звукового редактора Audacity 3.0"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Отдельный RSS теперь доступен для каждого обсуждения в форуме и каждого минипортала.
. "Выпуск звукового редактора Audacity 3.0" –2 +/
Сообщение от Ordu (ok), 18-Мрт-21, 20:26 
> Что-то я не понимаю с чего вы считаете будто бы считать бинарные
> блобы из SQLite эффективнее чем чем читать их как файлы стандартными
> средствами Ос?

Потому что я не считаю так. Речь ведь не о том, чтобы просто считать бинарные блобы, речь о приложении, которое работает с данными в файле. А работа с файлом может включать в себя не только последовательное чтение. Вот как ты будешь читать из файла? То есть, во-первых, ты будешь читать из файлА или из файлОВ? Наверное, всё же первое? Один файл и там поток сэмплов, так? Тогда, если тебе нужен блоб оттуда, что ты делаешь? lseek+read, так? В идеале хотелось бы так, потому как этот метод вряд ли чем-либо порвать удастся.

Но теперь прикинь, пользователь тыкает в интерфейсе и говорит "вот сюда я хочу вставить кусок звука". Что происходит на диске в ответ? А там паника, потому как стандартные средства фс не умеют расширять файл вставляя в середину кусок. Значит что надо делать? Вариант номер раз -- не сохранять почём зря, в надежде что приложение не упадёт, и электрик рубильником свет во всём доме не вырубит, и что промежуточный достигнутый пользователем результат не будет потерян. Вариант номер два -- читать с диска и перезаписывать полфайла. Вариант номер три -- разбить единый поток на маленькие блобы, и если что-то вставляется в середину, реально дописывать это в конец файла. Но тут тебе уже надо хранить в каком-то виде отображение времени от начала записи в смещение на диске. И это значит, что ты начал переизобретать базу данных и создавать её наколенную реализацию. И получится ли у тебя быстрее чем у sqlite -- это большой вопрос.

Эффективное же хранилище на жёстком диске, может открыть простор для того, чтобы а) сохранять промежуточный результат после каждого изменения, б) не хранить в памяти ВСЁ, хранить всё на диске, читая оттуда по мере необходимости, а это значит, что можно вместо сотен мегабайт или гигабайт ОЗУ под данные жрать ну, десятки мегабайт, наверное. Оу, это будет медленнее, чем всё хранить непосредственно в адресном пространстве процесса, но ровно до тех пор, пока у ОС достаточно оперативки: как только оперативка кончится, ОС начнёт свопить, и вот тут твоя производительность пойдёт лесом, в то время как вообще-то, если заточить приложение на хранение данных на диске, с чтением в память только нужного, то можно даже при нехватке оперативки под все данные, работать пускай не быстро, но и не запредельно тормозно. При этом, ежели у ОС достаточно свободной памяти, она закеширует содержимое диска, и будет не настолько уж и медленнее. Но сделать так, чтобы это "не настолько уж и медленнее" обеспечивало бы пристойную скорость работы на всём спектре железа которое используется под persistent storage и на всех ОС, на которых работает приложение -- это задача не для слабонервных, это задача для разработчиков бд.

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Выпуск звукового редактора Audacity 3.0, opennews, 17-Мрт-21, 21:33  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру