new road detection profiling

[Phibedy]

4-Kern Prozessor (intel i-5 irgendwas)

Gemessene Zykluszeiten (modul):

//Kerne
//0 5611	± 864	 [174; 8251]
//2 4621	± 908	 [186; 8584]
//4 4205	± 700	 [184; 10062]
//8 4185	± 681	 [169; 10982]
//32 4319	± 733	 [188; 9591]

Edit, die Zeiten sagen nichts aus, da das Umfeldmodell mit drinnen ist...

Umfeldmodell-Zeit: 1752 ± 425 [141; 3115]

Gemessene Zykluszeiten (nur die Suche):

// 0 3698	± 388	 [3448; 5147]
// 2 1931	± 944	 [9; 4484]
// 4 779	± 813	 [9; 5281]
//8 443	± 519	 [9; 3142]
// 32 559	± 624	 [9; 4285]

Man muss beachten, dass während der generierung der suchlinien schon gesucht werden kann, was die suchzeit verringert.

Die generierung der Suchlinien benötigt:

1321 ± 1014 [93; 4452]

@syxolk Vor allem, dass die Minimalzeit auch nach reset sich zwischen 9 und 17 ms bewegt zeigt, dass etwas mit dem nachrichten-senden über unix-domain-sockets nicht ganz stimmen kann, die bei einem Bild die gesuchten Punkte immer gleich sind. Wir sollten das Profiling auf dem Clienten machen und keine debug-nachrichten schicken und dann weiter debuggen.

[Phibedy]

Wenn man das malen ausstellt und --debug nicht angibt erhählt man beim Suchen mit 4 Kernen

new_road_detection.create lines              #828   ø 324  ± 594   [87; 2939]
new_road_detection.localCourse               #828   ø 1652 ± 242   [1466; 5218]
new_road_detection.search                    #828   ø 2094 ± 808   [4; 6880]

Die Zeiten haben sich verschoben, sehr komisch, aber zunächst sollten wir einen "Fehler" seitens des Frameworks ausschließen/beheben.