On 09.06.2014 19:46, Alexander Duda wrote:
Seriously, it is great that you are looking into it. But you are also
asking other people to help you costing them quite a bit of their free
time. Therefore, I think it is also fair for them to criticize
specific steps which might have little impact on the overall replay speed.
At the beginning, you were complaining about the replay speed and not
about the loading and alignment which you are currently improving. And
like Sylvain said. I also do not believe that the replay speed is so
slow because of the current pocolog implementation. It is slow because
of how rock-replay works (at least one callback per sample etc.).
Yep, the replay speed is still my main concern, but while fixing this, I
thought one could
catch the annoying index time on the way as well....
As removing streams from the replay increased the replay time (using
trace(false)) I am
pretty much suspecting the streamAligner... (and was right, see below)
And here is the point i criticize about the bashing from sylvain, he
didn't have a point
at all, and started bashing me for no reason. I have good reasons for
the things I do, and
I really hate it that I need to defend every step I make.
Anyway, I am a bit puzzled why you have different number of samples
for the same log files.
The log file is truncated, my implementation does not check for
truncates at the end of the stream atm.
Something in the pocolog implementation is the problem :
Using only polocog stream aligner to replay all samples
(I hacked the log implementation, to get the streamAligner directly,
and then called step on it in a while loop):
time ./test.rb ~/Arbeit/asguard/bundles/asguard/logs/current/
Replaying all samples
Orocos[WARN]: No ports are selected. Assuming that all ports shall be
replayed.
Orocos[WARN]: Connect port(s) or set their track flag to true to get rid
of this message.
pocolog.rb[INFO]: Got 79 streams with 263646 samples
pocolog.rb[INFO]: Stream Aligner index created
Done
real 0m56.849s
user 0m54.927s
sys 0m1.832s
Using the Cpp implementation including type unmashaling :
time ./multiIndexer ~/Arbeit/asguard/bundles/asguard/logs/current/*.log
Building multi file index
100% Done
Processed 263647 of 263647 samples
Replaying all samples
99% DoneCould not load sample data of sample 8211 of stream
/laser_filter_front.filtered_scans stream size 8212
First sample time 20140609-21:28:33:145982 last sample time
20140609-21:29:41:690300
Took 10.137.364 realtime 68.544.318
real 0m10.864s
user 0m9.189s
sys 0m1.660s
Typelib marshaling is not a big problem here, makes a difference of 2
seconds in user time.
Greetings
Janosch
_______________________________________________
Rock-dev mailing list
[email protected]
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev