Зачем GTK ( и, вероятно, Qt ) так часто обращается к диску?

По цифрам почти то же самое. HD 7660D

Основная фича btree - уменьшение обращений к диску, которые на порядки медленнее работы с памятью.

Что касается технологии SSD, то наивно думаю, что так как перемещения головок нет, то и скорость доступа к данным выше.

При разработке алгоритмов нужно также учитывать для каких объёмов данных они пригодны.

btree спроектирована неплохо и для многих задач её вполне можно использовать.

Буквально на этой неделе думал о том, что хорошо бы почту в реляционную бд запихать, искалось бы все не по 2-3 минуты, а по 10-20 секунд край(по факту 1-2 секунды), при этом очевидно что и как там было бы искать. И тут ты.

Жаль последний релиз этой маниту в 2017 году. :(

Наверное, исходили из того, что пользователь только после старта программы (и изредка при использовании) передвигает окно куда надо и подбирает размер. А не делает это слишком часто.

сохраняет … и при изменении размеров ещё и их тоже в файл конфигурации.

Вспомнил, с какой прогой были проблемы. Meld.

• Performance issue - High I/O on dconf due to GTK (21.11.2018)

Там упоминается:

• GSettings spurious «changed» signals (30.10.2017)

Но ведь вынос в отдельный поток полезен при любых вариантах использования. Может патч заслать?

Ну вот к кедах (кажется 4-ых) такого не было. Может и в 5-ых нет, но не проверял на магнитном.

Это – не список возможностей

Да ладно, вопрос был про то, что мы там такого в Fedora можем. Вот, можем использовать свежий ванильный Gnome из коробки. Ведущий себя так, как задумано разработчиками.

На секундочку, я в первом комментарии про него и писал.

говорить девуанщику что тебе доступен системдэ в отличии от меня – сродни попытке рассказать вегану что у тебя есть возможность есть мясо

Понятно, то есть это религиозное.

Вообще-то, лет пятнадцать уже прошло, уже давно можно пользоваться, в 99,9% случаев все так и делают.

Gnome, свежий софт.

мне, конечно же, доступны

Внезапно, бывает софт и посвежее. И Gnome не покалеченный.

Ну-да, ну-да: твой systemd+waylang+gnome конечно же способен летать на EeePC 2008 года, это только у композитора xfce проблемы.

Можно было бы попробовать ради интереса, к слову. Я не удивлюсь, если действительно отрисовка окошек тормозить перестанет.

У меня где-то валяется ноутбук 2012 года с Xfce и 4 Gb RAM, надо как-нибудь накатить туда обычный Fedora Workstation и посмотреть как оно в сравнении.

EeePC 2008 года, к счастью, у меня нет.

Это субъективное суждение: я осознанно выбираю десктоп w95-like

Конечно, субъективное. Но я тоже долгое время осознанно выбирал win95-like и не представлял как жить без свёрнутых окошек на панели. Оказалось, без них даже лучше.

Теперь осознанно выбираю Gnome.

С Wayland не припомню, чтобы у меня что-то тормозило

На HDD?

Нет, систему и домашний каталог не держу на HDD уже лет десять.

Поначалу тоже переживал, что система постоянно что-нибудь пишет на диск. Мол, как же так, лимит же, диск же угробится. Но ничего, все мои SSD живы до сих пор.

Надо было не диск покупать, а переехать на i3/swaywm. И удивится, насколько все быстро может работать, в отличии от gnome, kde, xfce, и прочих де. Разобраться и настроить можно за один вечер, эти 8 гиг озу станут в итоге с избытком.

Да ладно, вопрос был про то, что мы там такого в Fedora можем. Вот, можем использовать свежий ванильный Gnome из коробки. Ведущий себя так, как задумано разработчиками.

Принимается. А между гномом в федоре и гномом в дебиане/девуане есть различия?

говорить девуанщику что тебе доступен системдэ в отличии от меня – сродни попытке рассказать вегану что у тебя есть возможность есть мясо

Понятно, то есть это религиозное.

Понятно, ты либо не понял о чем я, либо юлишь

Вообще-то, лет пятнадцать уже прошло, уже давно можно пользоваться, в 99,9% случаев все так и делают.

А я и не спорю что можно пользоваться. А можно и не пользоваться: линукс – он про свободу выбирать чем пользоваться

бывает софт и посвежее. И Gnome не покалеченный.

Я принципиально не смогу собрать/поставить себе свежий гном?

Я не удивлюсь, если действительно отрисовка окошек тормозить перестанет.

А я – удивлюсь

EeePC 2008 года, к счастью, у меня нет.

есть qemu

С Wayland не припомню, чтобы у меня что-то тормозило

На HDD?

Нет, систему и домашний каталог не держу на HDD уже лет десять.

Ну тогда не корректно сравнивать: как ты видишь на ССД у меня и иксы не тормозят

Надо было не диск покупать, а переехать на i3/swaywm

Есть опыт? На ХДД?

прочитать и распарсить css, которая в куче файлов

В qt(qss) по хорошему собирается один раз в один файл. И грузится на старте.

Зачем GTK ( и, вероятно, Qt ) так часто обращается к диску?

Примерно любой визуальный фреймворк тихо-незаметно изобретает что-то типа PersistentObject, известный еще с дельфей, (например, «The QSettings class provides persistent platform-independent application settings.»), и ложит содержимое полей в «постоянную память» (ну какая уж есть, мапленые файлы это, сериализация/десериализация скалярных полей или целый ORM под капотом ходящий по указателям и ссылкам). Но обычно это не проблема, т.к. все это кэшируется и буферизируется (если есть куда). Вот если программистам развесистых визуальных иерархий изменяет чувство меры или «SSD уже у всех и как можно жить без 64 гектар ОЗУ?» – тогда становится очень заметно. Это не считая собственно своппинга.

ОЗУ сколько?

ну ответ напрашивается :)

А ещё, кто-то из разработчиков дисковой подсистемы kernel-а где-то в 2016-17г. придумал просто светить лампочкой раз в 2 сек. даже при отсутствии IO. Типа heartbeat - дисковая подсистема всё ещё жива.

Офигеть! А я то думаю, кто это у меня в компе с такой завидной периодичностью к диску обращается в простое. Вот ведь извращенцы чортовы! Никому\ничему уже нельзя доверять, даже лампочке на корпусе.

iotop покажет тебе что-нибудь типа jdb2/sdg2-8.

Нет никаких архитектур. Есть скорость отличающаяся настолько, что возвращаться на вращающуюся фигню просто не хочется.

У меня два винчестера, hdd и ssd. На ssd установлена фряха + KDE, на hdd Haiku.

Так вот, Haiku на HDD работает примерно как KDE на SSD. И запускается примерно столько же по времени.

На haiku вроде бы вообще ни одна видеокарта не работает

Да, именно так. Мы выводим весь GUI через телетайп.

Речь очевидно про ускоренную графику.

Есть опыт? На ХДД?

Есть машина с 8 гиг озу, на ней стоит hdd + debian + swaywm. Потребление озу на sway минимальное, поэтому есть большой дисковый кеш. Первое обращение к файл долгое, а вот повторные быстрые, ибо запрос уходит не к hdd а к кешу, который находится в озу.

Если использовать тупо в стиле XFS/ext4, то <…> мгновенное копирование за счёт рефлинков

Так это и в XFS доступно.

Haiku на HDD работает примерно как KDE на SSD

Тоже, что-ли, поставить на реальный винт да на досуге попытаться перетащить на неё свои задачи? Чем-то она мне так нравится..

озу занимает пять -семь секунд

неа. Чтение из памяти – всегда burst-ми, с расчетом на заполнение линии кэша. Плюс можно нарваться на цикл обновления памяти. Плюс на какой-нибудь вредный DMA (типа видео- или сетевой карты, которые прям щас кусок памяти в свой буфер складывают).

Основная фича btree -

… - это двоичное дерево поиска.

Ганс Рейзер и Шишкин Эдуард что-то писали про «теорию деревьев» в Reiser3fs и Reiser4fs соответственно. Что необязательно двоичное, а более алгоритмы на деревьях могут быть выгоднее. (https://habr.com/ru/articles/559014/)[например]

Но это далее тема флеймообразующая.

В бтрфс на мой взгляд, более правильное не фрагментация (свободного места, внутренняя) – а возможность использования снапшотов r/o или клонов r/w как в ZFS примерно (собственно, это скопировано оттуда)

Далее в общем-то можно делать и не двоичное, или какие-то более продвинутые алгоритмы для дедупликации или какие-то фичи типа клонов, снапшотов и репликации.

Но в общем, остаётся вопрос – насколько это всё эффективно при типичной или разнообразной нагрузке (много мелких файлов типа иконок или конфигов) или кеширования страниц памяти целиком (например, глобалей мумпса)

в общем, тут вопрос на тему оценки проектных tradeoff: что лучше, сделать объекты некоторой контент-адресуемой памяти на уровне файловой системы (под конкретные виды файлов и её нагрузки) или кешировать на основании структур данных СУБД (и изобретать какие-то структуры данных поверх неё)

Глобали МУМПСа – вообще, вещь довольно эпичная. Местами даже покруче «Фауста» Гёте.

Вот например, была операционка под PDP-11 ДИАМС (который DSM-11).

Сразу с дискетки вместо ОСРВ RSX-11 или подобного недоДОСа недоCPM-а грузились в ядро СУБД. При генерации и переконфигурации ядра ОС=СУБД – пересобирали ядро СУБД, написанное на ассемблере (сам ассемблер был написан на МУМПСе – то есть, фактически самоприменимая самораскрутка с нуля, без всяких прочих утилит и вообще без операционной системы)

Ядро МУМПСа = «кеширующий сервер глобалов и рутин»

то есть:

есть такой недофортран = язык ФОКАЛ (гусары, молчать!)

если фортран конпелируемый – то ФОКАЛ примерно тоже самое, среднее между фортраном и бейсиком – но интерпретируемое.

оно интерпретируется в байткод (и там есть заморочки типа naked указателя или косвенности, то есть, не всё в принципе возможно отконпелировать – да и не нужно)

который потом выполняется типа виртуальной машиной.

основная структура данных глобал = ~S-выражения~ ~матрицы APL~ тензор, то есть, массив.
то есть: разреженный массив который хранит только непустые значения. значения = строки или числа в строковом (каноническом представлении) или байтовые строки.

массив используется как хеш-таблица вида (много,ключей)->одно значение.

типизации нет, first class objects хранить нельзя, указателей нет (но есть имена, которые можно проинтерпретировать косвенностью)

то есть значения – строки или байтовые строки или числа как строки

то есть, опять таки моноид – как и S-выражения или стеки в конкатенативном каком-нибудь функциональном форте типа фактора или постскрипта – или point-free notation в каком-нибудь матричном APL с комбинаторами (тут правда, скорее по K и Qdb нужно упарываться).

в итоге стандартный голый MUMPS как язык достаточно некрасив – не в смысле того, что ключевые слова как и в ФОКАЛе можно до одной буквы сокращать – а в смысле того, что язык таки сильно строчно-ориентированный, начиная от интерпретатора виртуальной машины с отладчиком и обращением по номерам строк (или вложенности с «.» и синтаксически значимыми обычными и двойными пробелами, лол). заканчивая собственно структурами данных – в которые в строки нужно заворачивать вручную.

индексы, например, тоже делать вручную.

зато есть рутины. то есть, не просто повторно используемые хранимки. а которые можно запускать многозадачно как сопрограммы (через JOB).

в голом каноническом МУМПСе примерно как в том же ФОКАЛе – никакого ООП есть, но есть CHUI и зачатки GUI и модели событий.

в CacheObjectScript – наворотили ООП. в ProfileScript Language из GT.M – аналогичное COS только с открытыми исходниками.

в MSH – пожалуй, самое навороченное расширение. объекты, события, типизация, оконный интерфейс и GUI на GTK. жаль, автора MSH на хабре затролили (я так думаю, они все просто ниасилили МУМПСы).

для значений, которые представлены строками – есть ограничения на максимальный размер, обычно кратный размеру страницы ОС в подкачке (и этот размер страницы СУБД примерно 32k или 64kбайта)

в итоге BLOB-ы нужно хранить в каком-то формате, разбор которого придумать вручную. например, сделать «чанки» кратные 32 или 64к, и хранить количество полных + хвост размером остаток от деления на размер чанка. это если чанки бинарные строки, то есть, файлы бинарные.

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

файловая система BFS из BeOS (и далее в хайку) – кстати, была одной из первых в которой использовалась в качестве СУБД (например, много метаданных и запросы на SQL файловой системе)

наверное, можно и много других структур данных более эффективных придумать – деревьев не обязательно двоичных.

к чему это я всё. я тут экспериментирую с литературным программированием и запихиванием его в мумпсы.

взял вместо системы сборки redo с вариантами; в качестве литературно-грамотного – noweb,nuweb,noweb.py, funnelweb-utf8,slit2; в качестве текстового процессора – heirloom troff, groff, latex, lout, SILE, skribe, pollen(dr.racket) и ещё какой-то из XML-ей в PDF написанный на Go. ещё с asciidoctor экспериментирую и pandoc.

и пытаюсь всё это скрестить.

в конечном итоге, используя вот это литературно-грамотное – переписываю redo и noweb на МУМПСы.

чтобы работало «write once, run everywhere». под любым мупмсом, то есть (а то noweb запустить через icon а не awk под виндой – тот ещё квест, хехе)

метаязык литературно-грамотного noweb или slit2 тоже пытаюсь доработать – чтобы с моделями данных можно было проще работать. в смысле, не просто конструировать глобали руками кодом через KILL старого / SET нового (типа SQL скриптов накачивающих содержимое базы).

а чтобы генерировать на основании какой-то модели данных типа STEP EXPRESS, например.

…. в общем, это один из хобби проектов с которым я себе «в стол» медленно так ковыряюсь.

наткнулся на этот Маниту как-то случайно

просто подумал, что хорошо бы почту во что-то нереляционное – например, глобали МУМПСа запихать. с хранением в мумпсах не нашёл (хотя там и клиент и сервер протокола пишется элементарно) – а вот с хранением в пострге нагуглилось сразу же.

Жаль последний релиз этой маниту в 2017 году. :(

ну наверное, почтовый клиент уже идеальный :))

ведь он не должен сам почту рассылать, а просто выступать клиентом к постгре. а получение и рассылку – обычным MTA.

там уже плагинов штук несколько наклепали, с браузером на webkit и хранимками :))

Примерно любой визуальный фреймворк тихо-незаметно изобретает что-то типа PersistentObject, известный еще с дельфей, (например, «The QSettings class provides persistent platform-independent application settings.»)

вот буквально только что дочитал про Objective C и CoreData, как там это реализовано. а ещё Кушнера про «masters of doom» про то как Кармак с Ромерой на NeXT с WebObjects суровый энтерпрайсный редактор уровней с совместным редактированием всем офисом на этих freeze dried objects запиливали.

там хранятся plist в key-value которое тоже прозрачно сериализуется, объектно-ориентированно и с рефлексией так в этой core data.

изобретают очередной такой велосипед, в надежде что всё это эффективно скешируется.

хотя я вот подумал – и мне лично вместо браузера с 4957 вкладками отлично бы зашёл какой-нибудь OmniWeb (который вроде на вебкит был).

только на лиспе, типа Nyxt и с открытыми исходниками. чтобы допилить какой-нибудь поиск по содержимому или там метаданным.

в общем – нормальный такой scrapbook организовать, с поиском и библиотекаршами.

и ещё какой-то из XML-ей в PDF написанный на Go

ЕМНИП, это speedata