<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 09.06.2014 19:46, Alexander Duda
      wrote:<br>
    </div>
    <blockquote cite="mid:25BDE511-A583-468A-81CD-26015B7752D8@dfki.de"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <div>
        <div>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.</div>
        <div><br>
        </div>
        <div>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.). <br>
        </div>
      </div>
    </blockquote>
    Yep, the replay speed is still my main concern, but while fixing
    this, I thought one could<br>
    catch the annoying index time on the way as well....<br>
    As removing streams from the replay increased the replay time (using
    trace(false)) I am <br>
    pretty much suspecting the streamAligner... (and was right, see
    below)<br>
    <br>
    And here is the point i criticize about the bashing from sylvain, he
    didn't have a point <br>
    at all, and started bashing me for no reason. I have good reasons
    for the things I do, and<br>
    I really hate it that I need to defend every step I make.<br>
    <br>
    <blockquote cite="mid:25BDE511-A583-468A-81CD-26015B7752D8@dfki.de"
      type="cite">
      <div>
        <div><br>
        </div>
        <div>Anyway, I am a bit puzzled why you have different number of
          samples for the same log files.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    The log file is truncated, my implementation does not check for
    truncates at the end of the stream atm.<br>
    <br>
    Something in the pocolog implementation is the problem :<br>
    Using only polocog stream aligner to replay all samples <br>
    (I hacked the log implementation, to get the streamAligner directly,<br>
    and then called step on it in a while loop):<br>
    time ./test.rb ~/Arbeit/asguard/bundles/asguard/logs/current/<br>
    Replaying all samples<br>
    Orocos[WARN]: No ports are selected. Assuming that all ports shall
    be replayed.<br>
    Orocos[WARN]: Connect port(s) or set their track flag to true to get
    rid of this message.<br>
    pocolog.rb[INFO]: Got 79 streams with 263646 samples<br>
    pocolog.rb[INFO]: Stream Aligner index created<br>
    Done<br>
    <br>
    real&nbsp;&nbsp;&nbsp; 0m56.849s<br>
    user&nbsp;&nbsp;&nbsp; 0m54.927s<br>
    sys&nbsp;&nbsp;&nbsp;&nbsp; 0m1.832s<br>
    <br>
    Using the Cpp implementation including type unmashaling :<br>
    time ./multiIndexer
    ~/Arbeit/asguard/bundles/asguard/logs/current/*.log<br>
    Building multi file index <br>
    &nbsp;100% Done<br>
    Processed 263647 of 263647 samples <br>
    Replaying all samples<br>
    99% DoneCould not load sample data of sample 8211 of stream
    /laser_filter_front.filtered_scans stream size 8212<br>
    First sample time 20140609-21:28:33:145982 last sample time
    20140609-21:29:41:690300<br>
    Took 10.137.364 realtime 68.544.318<br>
    <br>
    real&nbsp;&nbsp;&nbsp; 0m10.864s<br>
    user&nbsp;&nbsp;&nbsp; 0m9.189s<br>
    sys&nbsp;&nbsp;&nbsp;&nbsp; 0m1.660s<br>
    <br>
    Typelib marshaling is not a big problem here, makes a difference of
    2 seconds in user time.<br>
    Greetings<br>
    &nbsp;&nbsp;&nbsp; Janosch<br>
    &nbsp;<br>
  </body>
</html>