Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
build1940 braucht viel Prozessorleistung
#11
hi, ich habe unter Linux ähnliche probleme mit der 1940/41 auf verschiedenen Rechnern. insbesondere Depot-Windoies verlangsamen Simutrans sehr, und das auch auf Rechnern > 3GH
Zitieren
#12
Das die offenen Fenster Simutrans verlangsamen ist nicht ungewöhnlich und nicht zu ändern und war auch schon so seit bestehen von Simutrans (bzw. seit ich den Code kenne). Und die Industrie und Haltestellenfenster sind sehr nichtstatisch, da sich die Zahl der Ware ja ständig ändert (bzw. ändern könnte).
Zitieren
#13
Früher hatte ich versucht die Fenster so klein als möglich zu gestalten.

Es wurden jedoch immer mehr Wünsche nach neuen Features und mehr Anzeite/sterungselementen geäussert, so dass die Fenster heute teils deutlich größer und komplexer sind, und durch Simutrans' Art und Weise wie Fensterinhalte dargestellt werden, auch mehr Rechenzeit ziehen.
Blogger blog blog
Zitieren
#14
Zitat:Original von hellmade
hi, ich habe unter Linux ähnliche probleme mit der 1940/41 auf verschiedenen Rechnern. insbesondere Depot-Windoies verlangsamen Simutrans sehr, und das auch auf Rechnern > 3GH
Wenn man wie ich einen Rechner hat der etwas schwächer auf der Brust ist, dann kann man sich dadurch helfen, dass man "Pause" drückt und dann die entsprechenen Fenster (Depot und Liniendefinitionen sind die größten Zeit-Killer) bedient Das geht ganz gut und ich brauche das "Feature" nicht, dass Simutrans weiterläuft während ich größere Editionen vornehme.
Zitieren
#15
nunja, im pause-modus kann man aber leide keine Züge starten Sad

zudem vergleiche ich's ja mit der regulären 100.0, nicht mit einer Version von vor 3 jahren (oder so)
Zitieren
#16
Zitat:Original von hellmade
zudem vergleiche ich's ja mit der regulären 100.0, nicht mit einer Version von vor 3 jahren (oder so)

Dann kann es nicht das Problem sein von dem ich geschrieben hatte, sondern etwas das in den letzten Wochen passiert ist ...
Blogger blog blog
Zitieren
#17
Ist es bei dem Problem egal, welche gcc verwendet wid?
Rechtschreibfehler sind gewollt und unterliegen dem Copyright des Verfassers, es sei denn, sie sind expliziet unter die GPL gestellt ....

Für "Simutrans-Nightlys" und aktuelle PAK: http://nightly.simutrans-germany.com
Zitieren
#18
Wird hinicht noch getestet. Ansonsten verwende ich gcc4.
Zitieren
#19
build1942:

Es gibt Screenshots vom ksysguard zur Begutachtung. Wichtig ist die Grafik links oben mit der CPU load. cpu/user ist blau, cpu/sys ist rot dargestellt. Der ksysguard mit weiteren Hintergrundprozessen bringt die CPU load auf ca. 12%.
Tests jeweils mit frames_per_second = 12

frame12-ind6-gcc4.png zeigt den Start des Programms mit gcc4 kompiliert, dann ohne offenes Fenster und schliesslich mit 6 geöffneten Industriefenstern; wieder ist es genau das sechste, das die CPU auslastet.

frame12-ind6-gcc3.png zeigt den Start des Programms (Peak in der Mitte) mit gcc3 kompiliert, dann ohne, mit 2, 5 und 6 geöffneten Industriefenstern. Ein wesentlicher Unterschied zu gcc4 fällt nicht auf, auch nicht von der Bedienung her.

frame12-bksp-gcc3.png zeigt das Drücken von Backspace; der Tastendruck geschah etwa unter dem Wort CPU (ca. 40 Sek.), und wenn ich nicht auf die 2. Arbeitsfläche gewechselt hätte, wärs wohl noch länger gegangen.

sim-ind6-AF2.png zeigt Simutrans (auf der 1. Arbeitsfläche) etwa 3 Sekunden nach dem Wechsel von der 2. Arbeitsfläche.

sim-ind6.png zeigt in etwa den Bildausschnitt für obige Tests, erscheint so etwa 8 Sekunden nach dem Wechsel von der 2. Arbeitsfläche.


Angehängte Dateien Thumbnail(s)
                   
Zitieren
#20
Zitat:Original von Gotthardlok
Wird hinicht noch getestet. Ansonsten verwende ich gcc4.
dito
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste