Hello Kenton,
now I did some benchmarks, while Seek'ing though a FileInputStream.
The testing code looks like this:

t0(boost::posix_time::microsec_clock::local_time()); // initialize
fileInStream = new
  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 
For more options, visit this group at 

Reply via email to