(1) Normally micro-benchmarks involve running the operation in a loop many
times so that the total time is closer to 1s or more, not running the
operation once and trying to time that.  System clocks are not very accurate
at that scale, and depending on what kind of clock it is, it may actually
take significantly longer to read the lock than it does not allocate memory.

(2) Your benchmark does not include the time spent actually reading the
file, which is what I asserted would be much slower than re-allocating the
buffer.  Sure, the seek itself is fast but it is pointless without actually
reading.

(3) What memory allocator are you using?  With tcmalloc, a malloc/free pair
should take around 50ns, two orders of magnitude less than your 4us
measurement.

On Wed, Jan 20, 2010 at 2:17 PM, Jacob Rief <jacob.r...@gmail.com> wrote:

> Hello Kenton,
> now I did some benchmarks, while Seek'ing though a FileInputStream.
> The testing code looks like this:
>
>  boost::posix_time::ptime
> t0(boost::posix_time::microsec_clock::local_time()); // initialize
> boost::posix_time
>  boost::shared_ptr<google::protobuf::io::FileInputStream>
> fileInStream = new
> google::protobuf::io::FileInputStream(fileDescriptor);
>  boost::posix_time::ptime
> t1(boost::posix_time::microsec_clock::local_time());
>   // using Seek(), the function available through my patch
>  fileInStream->Seek(offset, whence);
>  boost::posix_time::ptime
> t2(boost::posix_time::microsec_clock::local_time());
>  // this is the default method of achieving the same
>  ::lseek64(fileDescriptor, offset, whence);
>  fileInStream.reset(new
> google::protobuf::io::FileInputStream(fileDescriptor));
>  boost::posix_time::ptime
> t3(boost::posix_time::microsec_clock::local_time());
>  std::cerr << "t1: " <<        boost::posix_time::time_period(t1,
> t2).length() << " t2: " << boost::posix_time::time_period(t2,
> t3).length() << std::endl;
>
> and on my Intel Core2 Duo CPU E8400 (3.00GHz) with 4GB of RAM,
> gcc-Version 4.4.1 20090725, compiled with -O2
> I get these numbers:
> t1: 00:00:00.000001 t2: 00:00:00.000003
> t1: 00:00:00.000001 t2: 00:00:00.000003
> t1: 00:00:00.000001 t2: 00:00:00.000004
> t1: 00:00:00.000001 t2: 00:00:00.000007
> t1: 00:00:00.000001 t2: 00:00:00.000002
> t1: 00:00:00.000001 t2: 00:00:00.000003
> t1: 00:00:00.000002 t2: 00:00:00.000003
> t1: 00:00:00.000001 t2: 00:00:00.000004
> t1: 00:00:00.000001 t2: 00:00:00.000004
> t1: 00:00:00.000001 t2: 00:00:00.000003
> t1: 00:00:00.000001 t2: 00:00:00.000004
>
> In absolute numbers, ~1 microsecond compared to 3-4 microseconds is
> not a big difference,
> but from a relative point of view, direct Seek'ing is much faster than
> object recreation. And since
> I have to seek a lot in the FileInputStream, the measured times will
> accumulate.
>
> Regards, Jacob
>
> 2010/1/19 Kenton Varda <ken...@google.com>:
> > Did you do any tests to determine if the performance difference is
> relevant?
> >
> > On Mon, Jan 18, 2010 at 3:14 PM, Jacob Rief <jacob.r...@gmail.com>
> wrote:
> >>
> >> Hello Kenton,
> >>
> >> 2010/1/18 Kenton Varda <ken...@google.com>:
> >> (...snip...)
> >> > As for code cleanliness, I find the Reset() method awkward since the
> >> > user
> >> > has to remember to call it at the same time as they do some other
> >> > operation,
> >> > like seeking the file descriptor.  Either calling Reset() or seeking
> the
> >> > file descriptor alone will put the object in an inconsistent state.
>  It
> >> > might make more sense to offer an actual Seek() method which can
> safely
> >> > perform both operations together with an interface that is not so easy
> >> > to
> >> > misuse.
> >>
> >> I agree, a 64bit Seek function would definitely be safer.
> >> Here is a patch for version 2.3.0 to add FileInputStream::Seek(). The
> >> patch also fixes a compiler warning.
> >> I also adopted my library to use this function and it seems to work.
> >> Regards, Jacob
> >
> >
>
--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.

Reply via email to