LINUX.ORG.RU
Форум — Talks  

[kde][plasma] что случилось с Aaronом?

 ,


0

2

++performance

Plasma uses a lot of files from disk, particularly when using QML and scripted Plasmoids, but also whenever something requests an image from the theme. The Package class is responsible for the former functionality and the Theme class for the latter. We already cache the results of the Theme rendering, but not the results of looking around on disk for the requested image. There is essentially no caching at all for Package: every request for a file sends it looking on disk for it.

The impact of this is relatively low thanks to caching by the operating system, but it isn't negligable. When we start thinking of smaller devices it becomes even less negligable. So while working on libplasma2 I decided something needed to be done.

This past week I started a refactoring of the Package classes so that less memory was used, both by using a smaller data structure on devices and by using an implicitly shared pointer for the private data (which improves things on all targets, including the desktop). PackageStructure went from being a data bearing class to a mutator of Package, which allows them to be properly shared between Package objects. I then added a lookup cache to Package.

The result was that the copy test (100k copies and deletions) went from ~2700ms to ~37ms, while 100k copies, file lookups and deletions went from ~3900ms to ~40ms. All while the memory footprint shrunk. Unfortunately, this isn't really backportable to libplasma1 as the changes that were required to achieve this were significant. These changes were on top of previous changes made in the refactoring of Package and PackageStructure which drew the data «closer» to Package and cut out a lot of collection creation and copying. So reasonably good wins there.

Theme also got a lookup cache, and the good news is that this is backportable and has, in fact, been cherry picked into both the 4.7 and master (will be 4.8) branches. There the results were striking as well: 100k lookups of 3 different files in the theme dropped from a little over 6 seconds to ~1/4th of a second. That's an order of magnitude improvement. Unlike with Package, overall this will end up taking a little more memory, but we're talking about a few kilobytes at most which isn't particularly significant compared to the time savings. Since Theme is used heavily and the same SVGs are asked for over and over again during a Plasma applications execution, this should have some very nice impacts at runtime.

http://aseigo.blogspot.com/2011/07/performance.html

★★★★★

Скоро будет libplasma2, старые плазмоиды отвалятся, везде будет засилье QML (уже переписывают имеющиеся) и радость.

ChALkeR ★★★★★
()

Всё в порядке, мы его похитили и коммитим из под его аккаунта. Потихоньку оптимизируем away всю плазму, и всё снова будет хорошо.

vasilenko ★★
()
Ответ на: комментарий от ChALkeR

> старые плазмоиды отвалятся

Теперь начали плазму переписывать? :)

bsdfun ★★★★★
()

Да ладно, вот выйдет Qt5 и опять всё сломается, не переживай :}

Deleted
()

А за месяц до выхода KDE SC 5.0.0 разработчики сделают SQLite дефолтным бэкендом для Akonadi с Nepomuk'ом и мы увидим полный гнумокрысоlxdeкапец! МУХАХА!

AX ★★★★★
()

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

Manhunt ★★★★★
()
Ответ на: комментарий от ChALkeR

>Кому нафиг сдался sqlite сейчас, когда там есть virtuoso в минимальной поставке?

Virtuoso временами начинает аццки жрать процессор.

AX ★★★★★
()
Ответ на: комментарий от AX

> Virtuoso временами начинает аццки жрать процессор.

Таки да, у меня на свежеустановленном kde 4.6.5 оно пыхтело часа три, пока не прибил.

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

melkor217 ★★★★★
()
Ответ на: комментарий от Deleted

Кстати, тут любят поднимать вопрос тегов и комментариев к файлам на уровне ФС, как альтернативу этой байде.

melkor217 ★★★★★
()
Ответ на: комментарий от AX

Виноват не он, а то, что его гоняет. А гоняет его индексация файлов.

У тебя два выхода:

  • fs.inotify.max_user_watches = 524288
  • отключить индексацию файлов вообще, если тебе не нужен поиск по содержимому файлов
ChALkeR ★★★★★
()
Ответ на: комментарий от ChALkeR

>Виноват не он, а то, что его гоняет. А гоняет его индексация файлов.

Дело не в индексации. virtuoso_t может загрузить процессор даже при отключённом strigi.

AX ★★★★★
()
Ответ на: комментарий от melkor217

И с построением запросов по ним?

Разницы не будет.

ChALkeR ★★★★★
()
Ответ на: комментарий от AX

А за месяц до выхода KDE SC 5.0.0 разработчики сделают SQLite дефолтным бэкендом для Akonadi с Nepomuk'ом и мы увидим полный гнумокрысоlxdeкапец! МУХАХА!

не дай-то бох, оперативки будет тратиться меньше, зато тормозить - горздо больше!

когда мало оперативки - можно купить еще памяти, но куда ты вставишь еще процессоров для sqlite?

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

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

Deleted
()
Ответ на: комментарий от ChALkeR

>Как воспроизвести?

Не знаю, просто загрузись в чистый профиль и отключи strigi. У меня virtuoso продолжает жрать проц неопределённое время. Ещё такое бывало после перехода на новую ветку со старым профиле. Я поначалу думал, что там какая-то конвертация происходит, но это продолжалось слишком долго.

AX ★★★★★
()
Ответ на: комментарий от megabaks

>чорд, много нерусских букаф

почени!


Аарон провёл серьёзный рефакторинг кода libplasma, а также добавил туда кэширование путей к файлам тем. Это должно увеличить производительность, а также снизить потребление памяти. (см. тесты)

Результаты первого мы увидим только в libplasma2, а второе уже включено в 4.7 и master (т.е. 4.8 и выше).

AX ★★★★★
()
Ответ на: комментарий от stevejobs

> но куда ты вставишь еще процессоров для sqlite?

Пора производить материнки специально для KDE. :D

geekless ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Talks