On Wed, Jan 20, 2010 at 14:17, 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;
Can you run this microbenchmark in a loop, say 10^6 times and use a couple of different offsets you jump back and forth - and then time the whole loop ? Just a single measurement is not terribly reliable even though it would at least suggest a trend here. > > 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. > > > >
-- 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.
