Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Test: KDE SC 4.7 auf dem Weg zur…

Performancegewinne?

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Performancegewinne?

    Autor: zilti 27.07.11 - 15:33

    Wie sieht es mit Netbooks aus, ist eine Performancesteigerung feststellbar? Bei mir ist 4.6 nämlich des öfteren etwas lahm, sodass ich mir überlege, auf dem Netbook auf E17 umzusteigen.

  2. Re: Performancegewinne?

    Autor: Seitan-Sushi-Fan 27.07.11 - 15:42

    KDE kann kaputte Treiber nicht reparieren. Fast alle Performance-Beschwerden gehen darauf zurück, dass manche Treiber gewisse OpenGL-Funktionen nur sehr langsam ausführen können.

  3. Re: Performancegewinne?

    Autor: zilti 27.07.11 - 17:24

    Nutzt denn KDE bei abgestellten Arbeitsflächeneffekten überhaupt OpenGL? Und trotzdem könnte es ja sein, dass sie da irgendetwas optimiert hätten.
    Ich sage ja nicht "Scheiss-KDE ist saulangsam". Mir ist bewusst dass ich meinem Netbook mit KDE 4 doch ziemlich viel zumute, insbesondere wenn dann noch Opera mit über 20 Tabs und ab und an IDEA offen ist.

  4. Re: Performancegewinne?

    Autor: Non_Paternalist 27.07.11 - 20:05

    Naja, hängt von deinem Netbook ab. Sofern Dein Netbook "älterer" Generation ist, kann dies durchauszutreffen, aber etwas modernere Netbooks haben mit KDE-Software wohl nicht mehr so die Probleme, zumal in den neueren Softwareversionen immer mehr und mehr Speicherregressionen und Performanceprobleme durch Optimierungen ausgebügelt werden.

    Sofern du dann noch vernünftige Treiberunterstützung hast, sollte es nicht allzu arg werden.

  5. Re: Performancegewinne?

    Autor: Hello_World 27.07.11 - 21:17

    Seitan-Sushi-Fan schrieb:
    --------------------------------------------------------------------------------
    > KDE kann kaputte Treiber nicht reparieren. Fast alle
    > Performance-Beschwerden gehen darauf zurück, dass manche Treiber gewisse
    > OpenGL-Funktionen nur sehr langsam ausführen können.
    Das sind einfach faule Ausreden, die niemanden weiter bringen. Wenn die Treiber die gewünschten Funktionen nicht schnell genug ausführen können, muss man es eben irgendwie anders machen. E17 beweist ja, dass es geht. Das ist viel schneller als KDE4, ohne deswegen schlechter auszusehen (eher umgekehrt).

  6. Re: Performancegewinne?

    Autor: zilti 27.07.11 - 21:28

    Hello_World schrieb:
    --------------------------------------------------------------------------------
    > Das sind einfach faule Ausreden, die niemanden weiter bringen. Wenn die
    > Treiber die gewünschten Funktionen nicht schnell genug ausführen können,
    > muss man es eben irgendwie anders machen. E17 beweist ja, dass es geht. Das
    > ist viel schneller als KDE4, ohne deswegen schlechter auszusehen (eher
    > umgekehrt).
    Ja, und weisst du, warum? Weil du Äpfel mit Birnen vergleichst. Wenn schon müsstest du E17 mit KWin vergleichen. KDE ist weit mehr als E17, da gibts noch viele Hintergrunddienste die laufen und eine Palette Libraries. Das hat man bei E17 viel weniger.

  7. Re: Performancegewinne?

    Autor: Giesi35 27.07.11 - 23:22

    zilti schrieb:
    --------------------------------------------------------------------------------
    > Wie sieht es mit Netbooks aus, ist eine Performancesteigerung feststellbar?
    > Bei mir ist 4.6 nämlich des öfteren etwas lahm, sodass ich mir überlege,
    > auf dem Netbook auf E17 umzusteigen.


    Das "Problem" bei KDE SC ist das Laden der teilweise großen Bibliotheken, was vor allem auf alten Rechnern merkbar ist. Nen Ansatz ist das Prelinking (http://wiki.ubuntuusers.de/prelink).

    zilti hat recht. Man kann einen Fenstermanager nicht mit einem SC (KDE SoftwareCompilation) vergleichen. KWin (der Fenstermanager von KDE) ist nur ein kleiner Teil des Ganzen.

  8. Re: Performancegewinne?

    Autor: Hello_World 28.07.11 - 01:58

    zilti schrieb:
    --------------------------------------------------------------------------------
    > Ja, und weisst du, warum? Weil du Äpfel mit Birnen vergleichst. Wenn schon
    > müsstest du E17 mit KWin vergleichen. KDE ist weit mehr als E17, da gibts
    > noch viele Hintergrunddienste die laufen und eine Palette Libraries. Das
    > hat man bei E17 viel weniger.
    Hintergrunddienste und Bibliotheken machen nicht irgendwie auf magische Art die grafische Oberfläche langsamer. Es geht mir einfach nur darum, wie langsam die Oberfläche unter KDE teilweise gezeichnet wird. Wenn ich beispielsweise systemsettings starte, sehe ich, wie erst ein leeres Fenster auftaucht und dann ca. 1/2 bis 1 Sekunde später wird der Inhalt gezeichnet. Und wenn ich das Fenster dann größer ziehe, tauchen am Rand immer wieder leere Bereiche auf, bis sich die Bedienelemente im Fenster mit einer sichtbaren Verzögerung der neuen Fenstergröße anpassen. Und das sehe ich seit Jahren unter KDE4, während E17 keine derartigen Probleme hat.

  9. Re: Performancegewinne?

    Autor: Seitan-Sushi-Fan 28.07.11 - 02:10

    Hello_World schrieb:
    -----------------------------------------------------
    > Das sind einfach faule Ausreden, die niemanden weiter bringen. Wenn die
    > Treiber die gewünschten Funktionen nicht schnell genug ausführen können,
    > muss man es eben irgendwie anders machen.
    Wenn hier jemand FAULE Ausreden anführt, dann DU. Du willst mit Deinen faulen Ausreden kaputte Treiber rechtfertigen. Möp, gilt nicht!
    Die Treiber sind diejenigen Komponenten, sie von Milliarden schweren Unternehmen (Intel, NVidia, AMD) geschrieben werden. KDE ist zum Großteil eine Community aus Hobby-Entwicklern, die nicht die Ressourcen oder gar die Verpflichtung hätten, um irgendwelche Treiber-Bugs herum zu programmieren.

    > E17 beweist ja, dass es geht.
    Wenn E17 was beweist, dann dass man so armselig sein kann und seit über 10 Jahren keinen finalen Release einer 0.17-Version hinzukriegen. E17 ist tot und zuckt nur noch.

  10. Re: Performancegewinne?

    Autor: scroogie 28.07.11 - 08:46

    >Es geht mir einfach nur darum, wie langsam die Oberfläche unter KDE teilweise
    >gezeichnet wird. Wenn ich beispielsweise systemsettings starte, sehe ich, wie erst ein
    >leeres Fenster auftaucht und dann ca. 1/2 bis 1 Sekunde später wird der Inhalt gezeichnet.
    >Und wenn ich das Fenster dann größer ziehe, tauchen am Rand immer wieder leere
    >Bereiche auf, bis sich die Bedienelemente im Fenster mit einer sichtbaren Verzögerung
    >der neuen Fenstergröße anpassen.

    Du könntest mal probieren eine Applikation von der commandline mit

    -graphicssystem raster
    oder eben
    -graphicssystem opengl

    zu starten, um zu sehen ob es am Grafiktreiber liegt.

  11. Re: Performancegewinne?

    Autor: Hello_World 28.07.11 - 09:26

    Seitan-Sushi-Fan schrieb:
    --------------------------------------------------------------------------------
    > Hello_World schrieb:
    > -----------------------------------------------------
    > Wenn hier jemand FAULE Ausreden anführt, dann DU. Du willst mit Deinen
    > faulen Ausreden kaputte Treiber rechtfertigen. Möp, gilt nicht!
    > Die Treiber sind diejenigen Komponenten, sie von Milliarden schweren
    > Unternehmen (Intel, NVidia, AMD) geschrieben werden. KDE ist zum Großteil
    > eine Community aus Hobby-Entwicklern, die nicht die Ressourcen oder gar die
    > Verpflichtung hätten, um irgendwelche Treiber-Bugs herum zu programmieren.
    Wayne interessiert's? Ich bewerte Software danach, wie gut sie funktioniert, nicht danach, wer sie geschrieben hat. Ob Riesenfirma oder Community ist mir da vollkommen wurst.
    Zumal mir auch noch niemand einen schlüssigen Beweis dafür präsentieren konnte, dass es wirklich an dem Treiber liegt. Ich zweifle nämlich daran.

    > Wenn E17 was beweist, dann dass man so armselig sein kann und seit über 10
    > Jahren keinen finalen Release einer 0.17-Version hinzukriegen. E17 ist tot
    > und zuckt nur noch.
    Offensichtlich hast Du E17 nie ausprobiert.

  12. Re: Performancegewinne?

    Autor: Hello_World 28.07.11 - 09:27

    scroogie schrieb:
    --------------------------------------------------------------------------------
    > Du könntest mal probieren eine Applikation von der commandline mit
    >
    > -graphicssystem raster
    > oder eben
    > -graphicssystem opengl
    >
    > zu starten, um zu sehen ob es am Grafiktreiber liegt.
    raster bringt wenig bis nichts, opengl macht es nur noch langsamer. Hardware ist eine Radeon 4200 (onboard) mit dem radeon-Treiber



    1 mal bearbeitet, zuletzt am 28.07.11 09:28 durch Hello_World.

  13. Re: Performancegewinne?

    Autor: Giesi35 28.07.11 - 12:26

    Ich habe genau dieselbe GraKa und bei mir läufts flüßig und einwandfrei!

    Hintergrund-Dienste und Bibliotheken machen die Oberfläche langsam! Die Bibliotheken werden dynamisch zur Laufzeit geladen! Das dauert natürlich und dann wird erst gezeichnet! Prelinking hilft ab!

  14. Re: Performancegewinne?

    Autor: Hello_World 28.07.11 - 20:13

    Giesi35 schrieb:
    --------------------------------------------------------------------------------
    > Ich habe genau dieselbe GraKa und bei mir läufts flüßig und einwandfrei!
    Das ist schön für Dich.

    > Hintergrund-Dienste und Bibliotheken machen die Oberfläche langsam!
    Nö, nicht per se. Es ist ja nicht so, dass Enlightenment keine Bibliotheken verwenden würde. Im Gegenteil.

    > Die
    > Bibliotheken werden dynamisch zur Laufzeit geladen! Das dauert natürlich
    > und dann wird erst gezeichnet!
    Wenn Qt erst noch geladen werden müsste, könnte es auch kein Fenster erzeugen, das kann also kein Grund sein. Zudem sind die Verzögerungen ja auch zu beobachten nachdem das Programm schon längst gestartet wurde und die Bibliotheken schon im Speicher liegen.

  15. Re: Performancegewinne?

    Autor: Seitan-Sushi-Fan 29.07.11 - 02:05

    Hello_World schrieb:
    -----------
    > Wayne interessiert's? Ich bewerte Software danach, wie gut sie
    > funktioniert, nicht danach, wer sie geschrieben hat.

    Wenn das so wäre, würdest Du auf die Treiber schimpfen.


    > Zumal mir auch noch niemand einen schlüssigen Beweis dafür präsentieren
    > konnte, dass es wirklich an dem Treiber liegt. Ich zweifle nämlich daran.
    Es gibt genügend Beweise, angefangen im Blog vom KWin-Hauptentwickler. Entweder bist Du zu faul, selbst nach Gründen zu suchen (das Blog kann man nämlich leicht finden), oder Du lügst verdammt frech.
    Wie auch immer: Die Beweise gibt es.

    > > Wenn E17 was beweist, dann dass man so armselig sein kann und seit über 10
    > > Jahren keinen finalen Release einer 0.17-Version hinzukriegen. E17 ist tot
    > > und zuckt nur noch.
    > Offensichtlich hast Du E17 nie ausprobiert.
    Hat doch gar nichts mit dem Thema zu tun.
    Dass das Enlightenment-Projekt seit ca. 10 Jahren an seinem 0.17-Release (aka. E17) arbeitet und er bis heute nicht fertig gestellt wurde, ist Fakt und hat rein gar nichts damit zu tun, ob man E17 ausprobiert hat oder nicht.

  16. Re: Performancegewinne?

    Autor: lear 29.07.11 - 10:38

    Hello_World schrieb:
    --------------------------------------------------------------------------------

    > Wenn ich beispielsweise systemsettings starte, sehe ich, wie erst ein leeres Fenster
    > auftaucht und dann ca. 1/2 bis 1 Sekunde später wird der Inhalt gezeichnet.
    Hört sich nach 'nem üblen Bug in der XSYNC implementierung an, der irgendwie in KDE 4.4 & 4.5 existiert hat und sporadisch aufgetreten ist, ab 4.6 aber gegessen sein sollte.
    Wenn es am Treiber läge, hätte das raster graphicssystem es überspielen sollen - das rendert auf der CPU und ist schneller als viele Treiber + GPU :-(

    Wenn es nicht KDE/KWin sondern systemsettings spezifisch ist, dauert das laden der Konfigurationsmodule (start) eben so lange (vielleicht liegt noch ein Haufen alter == ungültiger Plugins irgendwo rum? Starte es mal aus der Textshell)

    > Und wenn ich das Fenster dann größer ziehe, tauchen am Rand immer wieder
    > leere Bereiche auf, bis sich die Bedienelemente im Fenster mit einer
    > sichtbaren Verzögerung der neuen Fenstergröße anpassen.
    Das ist die Sache mit dem XSYNC Protokoll, daß das eigentlich vermeiden sollte. Allerdings können die Clients intern Resize events immer noch sammeln und im Batch ausführen, was je nach zu veränderndem Objekt (Größenänderungen können viele Positionskalkulationen resp. Skalierungen nach sich ziehen) die CPU deutlich entlastet. Das ist dann aber clientspezifisch und der selbe Client würde sich unter E17 genaus verhalten wie unter allen anderen DEs (und E17 ist schon irgendwo zwischen WM und DE)

    > Und das sehe ich seit Jahren unter KDE4
    wie wär's mal mit 'nem update (scnr) :-P

    PS: wo ist denn der Link zu Deinem Bugreport?

  17. Re: Performancegewinne?

    Autor: Hello_World 30.07.11 - 20:44

    Mit Trollen, die mich der Lüge bezichtigen, diskutiere ich nicht.

  18. Re: Performancegewinne?

    Autor: ap (Golem.de) 30.07.11 - 20:56

    Außer Beleidigungen sind keine Inhalte mehr in diesem Thread zu finden, deshalb wurde der Thread geschlossen.

    --
    Andy Prahl
    (Golem.de)

  19. Re: Performancegewinne?

    Autor: Hello_World 30.07.11 - 21:01

    lear schrieb:
    --------------------------------------------------------------------------------
    > Hört sich nach 'nem üblen Bug in der XSYNC implementierung an, der
    > irgendwie in KDE 4.4 & 4.5 existiert hat und sporadisch aufgetreten ist, ab
    > 4.6 aber gegessen sein sollte.
    Naja, hier tritt es mit KDE 4.6.5 jedenfalls noch auf.

    > Wenn es am Treiber läge, hätte das raster graphicssystem es überspielen
    > sollen - das rendert auf der CPU und ist schneller als viele Treiber + GPU
    > :-(
    >
    > Wenn es nicht KDE/KWin sondern systemsettings spezifisch ist, dauert das
    > laden der Konfigurationsmodule (start) eben so lange (vielleicht liegt noch
    > ein Haufen alter == ungültiger Plugins irgendwo rum? Starte es mal aus der
    > Textshell)
    systemsettings gibt nur eine Zeile aus, die offenbar nichts mit dem Problem zu tun hat ("systemsettings(2298)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:")

    > Das ist die Sache mit dem XSYNC Protokoll, daß das eigentlich vermeiden
    > sollte. Allerdings können die Clients intern Resize events immer noch
    > sammeln und im Batch ausführen, was je nach zu veränderndem Objekt
    > (Größenänderungen können viele Positionskalkulationen resp. Skalierungen
    > nach sich ziehen) die CPU deutlich entlastet. Das ist dann aber
    > clientspezifisch und der selbe Client würde sich unter E17 genaus verhalten
    > wie unter allen anderen DEs (und E17 ist schon irgendwo zwischen WM und
    > DE)
    Ja, unter E17 tritt das Problem nicht auf (also nicht dass wir uns missverstehen: Die Größenänderung eines systemsettings-Fensters ist immer noch lahm, aber wenigstens sind das Fenster selbst und sein Inhalt immer gleich groß.

    > wie wär's mal mit 'nem update (scnr) :-P
    >
    > PS: wo ist denn der Link zu Deinem Bugreport?
    Jetzt wo ich einen Hinweis auf die Fehlerursache habe (XSYNC), werde ich das wohl demnächst mal machen. Danke übrigens für das erste konstruktive Posting in diesem Thread.



    1 mal bearbeitet, zuletzt am 30.07.11 21:01 durch Hello_World.

  20. Re: Performancegewinne?

    Autor: lear 31.07.11 - 19:13

    Hello_World schrieb:

    > Ja, unter E17 tritt das Problem nicht auf (also nicht dass wir uns
    > missverstehen: Die Größenänderung eines systemsettings-Fensters ist immer
    > noch lahm, aber wenigstens sind das Fenster selbst und sein Inhalt immer
    > gleich groß.

    Ok, das ist was anderes - der Bug war gravierend (der Fensteraufbau konnte sich bei jedem update über mehrere Sekunden hinziehen), daß hier ist eher lästig und dürfte einfach zu fixen sein.
    (Das XSYNC protokoll funktioniert; wenn der client lange braucht pausiert kwin irgendwann die resize Versuche - es scheint nur so, daß die Fensterdecoration den resize auch bei Vergrößerungen kriegt wenn kwin den request zum client schickt und nicht erst wenn der sagt: "ok")

    Es hat hier bis eben (Arch, e17svn kommt gerade neu rein) unter E17 übrigens auch nicht richtig funtioniert - E17 scheint den selben Fehler in die andere Richtung zu machen, so daß bei Verkleinerungen zuerst der client und dann (mit deutlicher Verzögerung) die Dekoration verändert wird.

    Der einzige WM, bei dem es "richtig" läuft ist Compiz, allerdings sind resizes damit hier (verglichen mit allen anderen WMs) so uuuuunglaublich lahm, daß ich befürchte, daß der pixelweise resize requests versendet.
    => compiz und kwin mit compositing haben als workarounds texture stretching im Angebot.
    Nachteil: kein feedback über änderungen im client.
    Vorteil: unglaublich viel schneller =)

    > Danke übrigens für das erste konstruktive Posting in diesem Thread.
    Mal ganz unkonstruktiv, aber nicht böse gemeint: im golem oder heise forum rumzunölen bringt selten was - insbesondere nicht bei allen Themen außer Politik ;-)

  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Gesellschaft für Anlagen- und Reaktorsicherheit (GRS) gGmbH, Köln
  2. Cluno GmbH, München
  3. AraCom IT Services AG, Augsburg, München, Stuttgart, Bamberg
  4. Ruhrverband, Essen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. PSN Card 20€ für 17,99€, Assassin's Creed Odyssey für 24,99€ und Tropico 6 für 31...
  2. (u. a. Fallout 4 GOTY für 26,99€ und Season Pass für 14,99€, Skyrim Special Edition für 17...
  3. (u. a. Logitech G910 + G402 für 99€ und ASUS Dual Radeon RX 580 OC + SanDisk SSD Plus 240 GB...
  4. (aktuell u. a. Corsair CX750 für 64,90€ + Versand)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Raspi-Tastatur und -Maus im Test: Die Basteltastatur für Bastelrechner
Raspi-Tastatur und -Maus im Test
Die Basteltastatur für Bastelrechner

Für die Raspberry-Pi-Platinen gibt es eine offizielle Tastatur und Maus, passenderweise in Weiß und Rot. Im Test macht die Tastatur einen anständigen Eindruck, die Maus hingegen hat uns eher kaltgelassen. Das Keyboard ist zudem ein guter Ausgangspunkt für Bastelprojekte.
Ein Test von Tobias Költzsch

  1. Bastelcomputer Offizielle Maus und Tastatur für den Raspberry Pi
  2. Kodi mit Raspberry Pi Pimp your Stereoanlage
  3. Betriebssystem Windows 10 on ARM kann auf Raspberry Pi 3 installiert werden

Fitbit Versa Lite im Test: Eher smartes als sportliches Wearable
Fitbit Versa Lite im Test
Eher smartes als sportliches Wearable

Sieht fast aus wie eine Apple Watch, ist aber viel günstiger: Golem.de hat die Versa Lite von Fitbit ausprobiert. Neben den Sport- und Fitnessfunktionen haben uns besonders der Appstore und das Angebot an spaßigen und ernsthaften Anwendungen interessiert.
Von Peter Steinlechner

  1. Smartwatch Fitbit stellt Versa Lite für Einsteiger vor
  2. Inspire Fitbits neues Wearable gibt es nicht im Handel
  3. Charge 3 Fitbit stellt neuen Fitness-Tracker für 150 Euro vor

Linux: Wer sind die Debian-Bewerber?
Linux
Wer sind die Debian-Bewerber?

Nach schleppendem Beginn stellen sich vier Kandidaten als Debian Project Leader zur Wahl. Zwei von ihnen kommen aus dem deutschsprachigen Raum und stellen Golem.de ihre Ziele vor.
Von Fabian A. Scherschel

  1. Betriebssystem Debian-Entwickler tritt wegen veralteter Werkzeuge zurück
  2. Linux Debian-Update verhindert Start auf ARM-Geräten
  3. Apt Bug in Debian-Paketmanager feuert Debatte über HTTPS an

  1. Google Earth: Virtuell durch die US-Nationalparks spazieren
    Google Earth
    Virtuell durch die US-Nationalparks spazieren

    Zur Nationalpark-Gedenkwoche in den USA ermöglicht es Google, über Google Earth 31 der 59 Parks kennenzulernen. Über kleine Touren lassen sich die Weite des Grand Canyon, die Hoodoos des Bryce Canyon oder die Bäume des Redwood-Nationalparks anschauen.

  2. Patentstreit: Apple zahlt wohl bis zu 6 Milliarden US-Dollar an Qualcomm
    Patentstreit
    Apple zahlt wohl bis zu 6 Milliarden US-Dollar an Qualcomm

    Die Streitigkeiten zwischen Apple und Qualcomm sind beendet, über die Höhe der vereinbarten Zahlungen herrscht allerdings Schweigen. Ein Analyst geht davon aus, dass Apple fünf bis sechs Milliarden US-Dollar zahlt. Dazu kommen noch bis zu neun US-Dollar Lizenzgebühren pro iPhone.

  3. Elektronikhändler: Media Saturn soll vor drastischem Stellenabbau stehen
    Elektronikhändler
    Media Saturn soll vor drastischem Stellenabbau stehen

    Bei Media Markt und Saturn stehen offenbar starke Einschnitte bevor: Wie Insider berichten, sollen Hunderte Stellen abgebaut werden. Besonders betroffen soll die Verwaltung der Kette in Ingolstadt sein.


  1. 16:00

  2. 15:18

  3. 13:42

  4. 15:00

  5. 14:30

  6. 14:00

  7. 13:30

  8. 13:00