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.
