Оптимизация GNOME

>правильно, в угоду фридесктоповцам перешли на DBUS с DCOP. И что?

ничего. Попробуй подумать и скажи, почему fd.o не выбрали DCOP в качестве стандарта. Подсказка - я всегда это говорил :)

>> Так гном врое только при загрузке конфиги считывает? Не понимаю как это влияет на последующую работу. Это только венда делает по несколько десятков обращений к реестру в секунду при простое.

>Ты думаешь? А как им, интересно, удаётся instant apply без перечитывания/переписывания конфигов? Вот тут-то и тормоза, как мне кажется.

Ес-но. Только часто ли ты правишь глобальные настройки? Надо монитор делать для этого gconf'а, или написать софтину, заменяющую его, и использующую например xrdb (с дополнением) или другой нормальный формат.

вроде на любой текст в структуре появляются дополнительные элементы типа text, и ихнужно пропускать... сам столкнулся :(

Разработчики Ubuntu сделали важное открытие: оказывается все тормоза гнома можно свалить на медленный парсер.

Даёшь компилятор XML %)

Давным давно уже в libxml2, да и во многих других библиотеках (причем, нередко, неявно) есть опция игнорирования whitespaces при отсутствии в элементе другого текста. Восстановление при парсинге исходного документа становится действительно невозможным, однако на вывод это никак не влияет, так как опять-таки, специальная опция форматирует xml-дерево требуемым образом.

Тут может играть роль, устанавливаются ли иные программы. Потому что, как показывает проект, выполненный в предыдущем Google Summer of Code каким-то чуве под руководством Owen'а, проблемы возникают из-за множества файлов с дефолтными настройками (находящихся в /etc). Для решения проблемы предлагается уже существующая и входящая в gconf утилита, объединяющая все файлы в 1, который парсится существенно быстрее. Без всяких "оптимизаций".

> ну я же говорил, у кдеешнегов комплекс относительно гконфа =))
Зато нам ускорялки - чистилки реестра - оптимизилки нафиг не упали, и так все шустренько работает. Гы.. :)))

> Зато нам ускорялки - чистилки реестра - оптимизилки нафиг не упали, и так все шустренько работает. Гы.. :)))

песочку принеси дорогой, в каком месте гконф - реестр?

>песочку принеси дорогой, в каком месте гконф - реестр?

тихо! только не говори ему что для кде твикеры есть. А то он же удавится

> Даёшь компилятор XML %)

Гы-гы. Юра Хныкин уже сделал компилятор компонентов, описанный в XML. И я его использую в E/AS. :)

Почему бы собственно вообще не сделать backend отделяемым. Хочешь - это XML storage, не хочешь будет тот же sqlite или db2, если по вкусу обычные plain-text файлы - пожалуйста. Кому надо интеграцию посредством XML - пользуется одним бэкэндом, кому производительность на чтении настроек - БД, кому на записи - plaintext файлами (или еще чем). Если у gconf'а API зафиксирован - имхо всё это возможно.

Тривиальная - значит выполняющаяся за 0 тактов и требующая 0 бит памяти?

backend уже давно отделяем в гконф. И даже есть всякие разные реализации.

Что-то тут путают оптимизацию с обыкновенным парсингом :)

> Тривиальная - значит выполняющаяся за 0 тактов и требующая 0 бит памяти?

Нет, это значит, что свой парсер DOM написать очень просто. :)

> Что-то тут путают оптимизацию с обыкновенным парсингом :)

Нет, всё верно. Десериализация позволяет повысить производительность. :)