Interessantes Phänomen ...

Discord Einladung
Trete unserem Discord-Server bei (klicke hier zum Beitreten).
  • Hallo.


    Die letzten Tage hat mir Railworks wieder einmal mehr Kopfzerbrechen bereitet. :D Und zwar kann ich es nicht verstehen, warum Strecken samt Scenario wesentlich schneller geladen werden, nachdem man zuvor den Cache geleert hat ( 15-20 Sekunden ) als ohne Cacheleeren die berühmten 90-120 Sekunden.


    Wenn ich es mit dem Internet vergleiche, dient Cache dazu, Seiten schneller wieder zu laden. Warum beobachte ich in Railworks nun das Gegenteil? Ist doch irgendwie irre, oder? Ich lösche jetzt jedes Mal immer den Cache. Weil das schadet eh nicht und außerdem lädt er die Strecken schneller. 8)


    Hat jemand da eine Erklärung? ;)

  • Das ist nicht bei allen leuten so. Bei mir verlangsamt das den Ladeprozess.
    Nein, ich habe keine Erklärung.
    Und ja, es ist unlogisch.

    Egal, wie weit Draußen man die Wahrheit über Bord wirft, irgendwann wird sie irgendwo an Land gespült.

  • Nein, ist es nicht. Zumindest nicht hier bei RW. Die nicht im Cache gespeicherten Inhalte werden nämlich nicht jedes Mal aus dem Internet nachgeladen, wie bei den Internet Browsern, sondern sind bereits auf der Festplatte vorhanden.
    Nach dem Nachladen einer neueren Version gibt es dann zwei Versionen der gleichen Datei. Die beiden Versionen sind anscheinend in einer Art Indexdatei gespeichert.
    Der Dateimanager von RW muß dann jedesmal nach beiden Versionen suchen, wenn die Indexdatei sagt, es gibt eine weitere Version dieses Objektes an einer anderen Stelle (im Cache?), um das "richtige" Objekt dann zu laden. Was manchmal auch zum Laden des falschen Objektes führt, wie viele Kollegen schon feststellen durften, bei denen es nach dem Leeren des Cache wieder funktionierte.
    Wenn der Cache geleert wird, wird die Indexdatei mitgelöscht. Beim nächsten Start wird die Indexdatei neu aufgebaut, was beim ersten Mal zu einem längeren Ladeprozess führen kann (siehe Prellbock). Danach wird dann nur noch an einer Stelle geschaut und das Laden sollte schneller gehen - bis zum nächsten Löschen des Caches.


    Ich hoffe, meine Vermutungen sind richtig, die Experten werden bei Bedarf sicher korrigieren.


    Gruß
    Norbert

  • Das Internet sollte da aussen vor sein.
    RW erstellt intern aus den Asset Dateien Blueprint.pak Dateien, diese werden beim Start und beim Spiel einer Strecke benutzt, in den Arbeitsspeicher geladen. Vermutlich binäre Dateien, die einen schnellen Zugriff bieten.
    Bisher war die Thorie so, wenn nichts im Asset-Ordner verändert wurde, nicht den Cache leeren, dann ist alles für den schnellen Zugriff vorbereitet.
    Info: Cache leeren = Blueprint.pak löschen. könnte man im Explorer auch zu Fuß tun, das Löschen ist nur umständlicher. Der Neuaufbau der .pak dauert nach dem Löschen halt wieder länger.
    jetzt ist das bei manchen Usern nicht so.
    Theorie zu Überprüfung: (reiner Schuss ins Blaue).
    Steam offline: das ist weiter so.
    Steam online: da wird an den Dateien online rumgefummelt, dann ist es nicht mehr so.
    StS

    Keine Hilfe und Auskunft per PN, da meist von allgemeinem Interesse. Diese Fragen bitte im Forum stellen.

  • Steam hat mit dem Cache von TS nix zu tun. Was der Cache macht ist ein Flat-Abbild der XML Struktur des gesamten Assetordners vorzuhalten. Der Loader überprüft auch nicht ob sich im Asset etwas gegenüber dem Flat verändert hat. Er lädt generell das Flat wenn vorhanden. Warum das manchmal länger dauert mit dem ding als ohne wird an der internen Struktur und der Verarbeitung liegen. Mäßig komplexe Objekte werden sicher schneller geladen ohne Cache als mit. Komplexe Strukturen und daraus schlussfolgernd viele Assets brauchen eben länger ohne Cache. Es kommt also drauf an was geladen wird. Hier dauert es grundsätzlich länger nach dem löschen des Cache. Bei einer SSD macht sich das aber kaum bemerkbar. Der Unterschied rangiert um die 3 Sekunden. Dass Strecken grundsätzlich länger dauern beim Laden hat noch ganz andere Ursachen, die mit dem Cache selber nichts zu tun haben.


    Eine Theorie wäre noch, welche aber nicht nachgewiesen werden kann, dass der Cache aufgebaut wird nach Anforderung des Loaders. Es ist nicht unbedingt davon auszugehen dass immer das gesammte Asset in den Cache wandert. Es ist tatsächlich möglich, dass nur angeforderte Objekte neu gecachet werden nach dem Löschen des Cache. Das würde auch Sinn machen und Kuju ist dies zuzutrauen soweit gedacht zu haben. Das hat dann natürlich zur Folge dass beim Laden einer Strecke mit anderen Loader Anforderungen dann der Cache nicht wirkt und das Asset ohne Cache geladen werden muss, was dann die längernen Ladezeiten mit vorhandenem Cachefile erklärt.


    alles nur Logik...

  • Ich hab ja aber eben das genaue Gegenteil. Wenn ich den Cache lösche, dann startet das Scenario innerhalb 20 Sekunden. Bereits das Nachladen würde schon wieder mindestens 100 Sekunden dauern. Also beim AUFGEBAUTEN CACHE dauert es bei mir länger als wenn er alles wieder neu aufbauen muss. ;)

  • Nein, ist es nicht. Zumindest nicht hier bei RW. Die nicht im Cache gespeicherten Inhalte werden nämlich nicht jedes Mal aus dem Internet nachgeladen, wie bei den Internet Browsern, sondern sind bereits auf der Festplatte vorhanden.

    Ein Cache ist nichts anderes als ein Puffer und sagt nichts über die Herkunft der zu puffernden Daten aus.
    Oder füllen sich deine L1-, L2- und L3-Caches deines Prozessors mit Daten aus dem Internet?

    Egal, wie weit Draußen man die Wahrheit über Bord wirft, irgendwann wird sie irgendwo an Land gespült.

  • Ich hab ja aber eben das genaue Gegenteil.


    Ja eben! Wenn der Cache vorher nach Anforderung augbaut wurde, dann aber nicht passt, wird er zwar geladen, aber ignoriert und das Asset wird anschliessen komplett neu geladen. Also dauert es länger, da 2 Ladevorgänge samt Verifizierungsfunktionen ablaufen müssen. der Cache hält einfach nicht alles vor was die Anforderung beinhaltet und so wird eben auf der Platt nochmal geschaut ob es nicht doch da ist.