Heap Size in V8

[Niklas Odendahl]

Hallo!

Ich habe eine Frage bezüglich der Konvertierung zu GTFS:

Ich habe versucht, die Konvertierung der Daten nach GTFS nachzustellen,

sprich die Datensätze über Node parsen zu lassen.

Leider bin ich auf das Problem gestoßen, dass NodeJS, respektive Google V8

(was ja die JS Engine von Node ist) ja leider nur eine maximale HeapSize von

 circa 1.4Gb zulässt. 

Ich habe versucht, die Höhe hochzuschrauben, das Vorgehen ist hier

beschrieben - leider ohne Erfolg. 

Hat jemand ein ähnliches Problem?

Testplattformen:

iMac - 2010er Modelljahr

MacBook Pro - 2011, 8Gb, i5 Dual Core, 2.5 GHz je

Server, 256 Gb RAM, 16 Xeon Prozessoren unbekannter Kernzahl und Taktrate, Ubuntu Server x64

MFG

Niklas Odendahl

[Michael Kreil]

Hi Niklas,

Ok, deine Frage trifft genau den wunden Punkt!

Die Begrenzung der V8-Engine ist tatsächlich genau das Bottleneck, warum wir die openPlanB-Daten noch nicht in vernünftigem GTFS haben. Man könnte zwar relativ leicht per File-Streams die Daten ziemlich 1:1 in GTFS umwandeln, aber das Ergebnis ist riesig und schlecht formatiert.

Interessanter Weise bin ich auf das gleiche Problem an anderer Stelle noch einmal begegnet, und zwar beim GTFS-Datensatz der VBB (http://daten.berlin.de/datensaetze/vbb-fahrplan2012). Die veröffentlichen Daten sind um den Faktor 100 zu groß, weil jeder einzelne Zug gespeichert wird, anstatt die erste Verbindung und die Taktrate. Eine erste Analyse hab ich mal hier veröffentlicht: https://github.com/MichaelKreil/jsRouting/tree/master/Analyse

Nach eigenen Recherchen ist das ein Problem, dass fast alle veröffentlichen GTFS weltweit betrifft. Scheinbar werden die GTFS-Daten weltweit nur so Pi-mal-Daumen aus proprietären System exportiert. Die Resultate sind aber größtenteils alle schei** formatiert.

Das ist also ein Problem, dass nicht nur openPlanB betrifft, sondern (fast) alle Verkehrsunternehmen weltweit. :/

Deswegen bin ich gerade in Gesprächen mit dem VBB. Die Hoffnung ist, dass wir ein GTFS-Entwickler_innen-Treffen organisieren können, dass vielleicht sogar von Google unterstützt wird. Dort könnte man einen GTFS-Werkzeugkasten entwickeln, um schlecht formatierte GTFS-Daten zu analysieren, zu visualisieren, zu säubern, zu mergen (BVG + S-Bahn), zu filtern (nach Anbieter/Monat/Region) und zu komprimieren (frequencies.txt).

Aktueller Stand dazu ist, dass solch ein Treffen irgendwann in der ersten Hälfte dieses Jahres stattfinden sollte.

Ich befürchte, dass ich damit deine Frage nicht wirklich beantwortet habe, oder? :/

Grüße,

Michael

[Niklas Odendahl]

Hi - danke für die Antwort!

Ja, das Problem ist mir bekannt - aus gegebenem Anlass durfte ich mit einem Kollegen  zusammen

den Export eines proprietären Systems rückentwickeln und aufdröseln. Die Zusammenhänge sind teilweise

sehr schwer nachzuvollziehen, schlussendlich haben wir aus dem Datensatz eines Anbieters einer 

mittelgroßen Statt (6 Linien zu je geschätzt 20 Stationen) ein Format gestrickt, was zwar leicht zu nutzen

war, dafür aber viele Schalter offen lies - "ein Anrufsammeltaxi an einem Samstag nach 10, welcher ein

Feiertag ist" muss halt auch abgedeckt weden =/

Aber back to topic- ja natürlich wäre eine Übereinkunft derart furchtbar sinnvoll, müsste aber halt viele

Einzelszenarien abdecken - sprich benötigt viel Vorarbeit der einzelnen Ortsgruppen mit den Verkehrsbetrieben.

Wie bekäme man denn von so einem Treffen Wind?

Und wie mache ich das jetzt mit V8? :D

MfG

Niklas

[Michael Kreil]

Hi,

Ihr unterstützt Verkehrsunternehmen mit Software, also auch beim GTFS-Export? So 'was hatte ich gar nicht auf dem Schirm! Aber gute Idee! Gleich mit ins Boot holen.

Wie bekäme man denn von so einem Treffen Wind?

Wenn da tatsächlich was Handfestes steht, würde ich das über alle Kanäle laufen lassen!

Und wie mache ich das jetzt mit V8? :D

Wie gesagt, irgendwo im Code müsste ein erstes GTFS-Export stehen. Ich glaube für stations.txt ... weiß aber nicht mehr genau ...

Sobald aber tatsächlich ein Werkzeugkasten stehen würde, könnte man in openPlanB einen "dreckigen" GTFS-Export mit File-Streams bauen, der ja keine Heap-Limitierungen hätte, da ja maximal ein Index oder so im Heap gehalten werden müsste. Heißt: Erst ein GTFS-Cleanup-Tool bauen, dann macht auch der GTFS-Export Sinn.

Grüße,

Michael

[Niklas Odendahl]

Hey, 

ya wir bauen da was für die lokalen Stadtwerke - sollte erst ein eigenes Format sein, respektives ist es,

aber dann haben wir  Wind von GTFS bekommen und hey - Google ist zukunftssicher.

Ich werd mich die Tage mal hinter die Node-Lösung (no pun intended!) klemmen und gucken,

wie der Export genau funktioniert, sonst kann ich eh nur halb mitreden wo das Problem liegt :)

Mal ne andere Frage, gabs nen speziellen Beweggrund zu Node? Ich mein hooray, non-blocking, ya,

JSON, woohoo - aber wäre da ne "ganz eigene" Lösung nicht etwas flexibler gewesen? Keine Kritik,

versuche mich nur in den Weg bisher einzufühlen.

MfG

Niklas

[Michael Kreil]

Als Entwicklungsumgebung wollte ich eine Sprache verwenden, die

1. die fähig ist, die Binärdaten zu verarbeiten,

2. weit verbreitet ist,

3. plattformunabhängig ist,

4. geringe Hürden hat bzgl. eines Einstiegs in das Projekt, (auch für Anfänger)

5. die es erlaubt, das Projekt mit wenigen Handgriffen zu einem Web-Server umzubauen.

Möglich wären also Java, Python und node.js, wobei die letzten beiden in die engere Wahl kamen.

Hätte ich mit dem Projekt eher Hacker ansprechen wollen, hätte ich mich für Python entschieden. Da die Hauptaufgabe aber darin lag, irgendwelche kryptischen Zahlenkolonen als Zugnummern, Gleise oder Bahnhofsausstattungs-Flags zu erkennen, habe ich mich für JavaScript entschieden, da ich glaube, dass es bei Bahn-Fans und -Mitarbeiter/innen mehr Menschen gibt, die was mit JavaScript anfangen können, als mit Python.

Die Begrenzung des Heaps war mir von Anfang an klar, aber jede Software/Hardware hat ihre Limits. Dank Streams und Pumps gab es aber unter node.js elegantere Lösungen der Umgehung.

... in my humble opinion ...

Grüße,

Michael

[Niklas Odendahl]

Hey,

der gute Guido würde sich im Grabe umdrehen, würde er merken, dass du sein Baby als Utensil Perl-verdrossener Hacker darstellst ;-)

Interessant, wir haben dafür Python in Benutzung - mal gucken, letztendlich kann man mit allem zum Ziel kommen!

MfG

Niklas