|
Hi,
I am trying to dump the XYZRGBA cloud stream from my Kinect on to my SSD with PCDWriter::writeBinaryCompressed(). the openni callback with the write command then takes around 100ms to finish and the size of one pcd file is around 1,66 MB. Is this to be expected or am I missing something? I am using the PCL trunk from 2 days ago on Windows 7x64, all libs are 32 bit, CPU Core i5 M560 2.6 GHz thanks Christoph Pacher |
|
Administrator
|
Cristoph,
100ms sounds excessive compared to my 25ms. I can either attribute this to a poorer performance of the SSD, or a Windows performance glitch. Can you please test the same code on a regular HDD and report back? I'd like to investigate this and optimize it further. Thank you in advance! Cheers, Radu. -- http://pointclouds.org On 03/19/2012 03:45 PM, Christoph Pacher wrote: > Hi, > > I am trying to dump the XYZRGBA cloud stream from my Kinect on to my SSD > with PCDWriter::writeBinaryCompressed(). the openni callback with the write > command then takes around 100ms to finish and the size of one pcd file is > around 1,66 MB. Is this to be expected or am I missing something? I am using > the PCL trunk from 2 days ago on Windows 7x64, all libs are 32 bit, CPU Core > i5 M560 2.6 GHz > > thanks > Christoph Pacher > > -- > View this message in context: http://www.pcl-users.org/writeBinaryCompressed-too-slow-tp3840585p3840585.html > Sent from the Point Cloud Library (PCL) Users mailing list archive at Nabble.com. > _______________________________________________ > [hidden email] / http://pointclouds.org > http://pointclouds.org/mailman/listinfo/pcl-users [hidden email] / http://pointclouds.org http://pointclouds.org/mailman/listinfo/pcl-users |
|
thanks for your fast response.
since i don't have a desktop to compare, I benchmarked a 2.5" usb 3.0 drive and a 3.5" esata drive on my laptop. usb 3 is worse with write times between 220 and 140 ms, esata is basically the same like my internal SSD with write times between 75 and 120ms. Anything else I can try? Some more background info: i am using OpenFrameworks for my main OpenGl App which runs in its own boost thread. The PCL pointcloud callback is a member of this App. I already disabled all the visual stuff, and just write the file in the callback with the current App running time in millisecs in the filename. Thanks! |
|
Hi Chris,
Could you try running the openni_grab_frame tool with the -no-end option? If that gets good performance, then the problem is not related to PCL. Cheers, Alex On 3/20/12 12:49 PM, Christoph Pacher wrote: > thanks for your fast response. > > since i don't have a desktop to compare, I benchmarked a 2.5" usb 3.0 drive > and a 3.5" esata drive on my laptop. usb 3 is worse with write times between > 220 and 140 ms, esata is basically the same like my internal SSD with write > times between 75 and 120ms. Anything else I can try? > > Some more background info: i am using OpenFrameworks for my main OpenGl App > which runs in its own boost thread. The PCL pointcloud callback is a member > of this App. I already disabled all the visual stuff, and just write the > file in the callback with the current App running time in millisecs in the > filename. > > Thanks! > > -- > View this message in context: http://www.pcl-users.org/writeBinaryCompressed-too-slow-tp3840585p3842093.html > Sent from the Point Cloud Library (PCL) Users mailing list archive at Nabble.com. > _______________________________________________ > [hidden email] / http://pointclouds.org > http://pointclouds.org/mailman/listinfo/pcl-users _______________________________________________ [hidden email] / http://pointclouds.org http://pointclouds.org/mailman/listinfo/pcl-users |
|
this is the list of the files the openni_grab_frame tool has written:
20.03.2012 14:49 1.960.897 frame_20120320T144930.853091.pcd 20.03.2012 14:49 1.962.489 frame_20120320T144930.954096.pcd 20.03.2012 14:49 1.962.085 frame_20120320T144931.015100.pcd 20.03.2012 14:49 1.962.370 frame_20120320T144931.113105.pcd 20.03.2012 14:49 1.962.395 frame_20120320T144931.184109.pcd 20.03.2012 14:49 1.966.375 frame_20120320T144931.253113.pcd 20.03.2012 14:49 1.965.632 frame_20120320T144931.313117.pcd 20.03.2012 14:49 1.967.354 frame_20120320T144931.383121.pcd 20.03.2012 14:49 1.963.961 frame_20120320T144931.442124.pcd 20.03.2012 14:49 1.962.817 frame_20120320T144931.513128.pcd 20.03.2012 14:49 1.966.599 frame_20120320T144931.611134.pcd 20.03.2012 14:49 1.966.473 frame_20120320T144931.683138.pcd 20.03.2012 14:49 1.964.266 frame_20120320T144931.769143.pcd 20.03.2012 14:49 1.964.655 frame_20120320T144931.853148.pcd 20.03.2012 14:49 1.964.032 frame_20120320T144931.970154.pcd 20.03.2012 14:49 1.963.021 frame_20120320T144932.052159.pcd 20.03.2012 14:49 1.967.307 frame_20120320T144932.141164.pcd 20.03.2012 14:49 1.960.302 frame_20120320T144932.213168.pcd 20.03.2012 14:49 1.963.080 frame_20120320T144932.310174.pcd 20.03.2012 14:49 1.966.794 frame_20120320T144932.414180.pcd 20.03.2012 14:49 1.967.251 frame_20120320T144932.483184.pcd 20.03.2012 14:49 1.964.649 frame_20120320T144932.553188.pcd 20.03.2012 14:49 1.965.271 frame_20120320T144932.654194.pcd I also made a small grab test project with just PCL writing the files without the OpenFrameworks app. when writing XYZRGBA files i get a callback runtime between 40 and 50 ms, which is still too slow class testGrabber { public: testGrabber (){} void cloud_cb_ (const pcl::PointCloud<pcl::PointXYZRGBA>::ConstPtr &cloud) { pcl::ScopeTime t ("grabber"); w->writeBinaryCompressed(std::to_string(counter) + ".pcd", *cloud); counter++; } void run () { interface = new pcl::OpenNIGrabber(); w = new pcl::PCDWriter; counter = 0; boost::function<void (const pcl::PointCloud<pcl::PointXYZRGBA>::ConstPtr&)> f = boost::bind (&testGrabber::cloud_cb_, this, _1); interface->registerCallback (f); interface->start (); while (true) { sleep (1); } interface->stop (); } // vs10 missing to_string(int) workaround long long counter; pcl::PCDWriter* w; pcl::Grabber* interface; }; //======================================================================== int main( ){ testGrabber t; t.run(); } |
|
The openni_grab_frame should print out the timing in the terminal. Check
those out. On 3/20/12 3:00 PM, Christoph Pacher wrote: > this is the list of the files the openni_grab_frame tool has written: > 20.03.2012 14:49 1.960.897 frame_20120320T144930.853091.pcd > 20.03.2012 14:49 1.962.489 frame_20120320T144930.954096.pcd > 20.03.2012 14:49 1.962.085 frame_20120320T144931.015100.pcd > 20.03.2012 14:49 1.962.370 frame_20120320T144931.113105.pcd > 20.03.2012 14:49 1.962.395 frame_20120320T144931.184109.pcd > 20.03.2012 14:49 1.966.375 frame_20120320T144931.253113.pcd > 20.03.2012 14:49 1.965.632 frame_20120320T144931.313117.pcd > 20.03.2012 14:49 1.967.354 frame_20120320T144931.383121.pcd > 20.03.2012 14:49 1.963.961 frame_20120320T144931.442124.pcd > 20.03.2012 14:49 1.962.817 frame_20120320T144931.513128.pcd > 20.03.2012 14:49 1.966.599 frame_20120320T144931.611134.pcd > 20.03.2012 14:49 1.966.473 frame_20120320T144931.683138.pcd > 20.03.2012 14:49 1.964.266 frame_20120320T144931.769143.pcd > 20.03.2012 14:49 1.964.655 frame_20120320T144931.853148.pcd > 20.03.2012 14:49 1.964.032 frame_20120320T144931.970154.pcd > 20.03.2012 14:49 1.963.021 frame_20120320T144932.052159.pcd > 20.03.2012 14:49 1.967.307 frame_20120320T144932.141164.pcd > 20.03.2012 14:49 1.960.302 frame_20120320T144932.213168.pcd > 20.03.2012 14:49 1.963.080 frame_20120320T144932.310174.pcd > 20.03.2012 14:49 1.966.794 frame_20120320T144932.414180.pcd > 20.03.2012 14:49 1.967.251 frame_20120320T144932.483184.pcd > 20.03.2012 14:49 1.964.649 frame_20120320T144932.553188.pcd > 20.03.2012 14:49 1.965.271 frame_20120320T144932.654194.pcd > > > > I also made a small grab test project with just PCL writing the files > without the OpenFrameworks app. when writing XYZRGBA files i get a callback > runtime between 40 and 50 ms, which is still too slow > > class testGrabber > { > public: > testGrabber (){} > > void cloud_cb_ (const pcl::PointCloud<pcl::PointXYZRGBA>::ConstPtr&cloud) > { > pcl::ScopeTime t ("grabber"); > > w->writeBinaryCompressed(std::to_string(counter) + ".pcd", *cloud); > counter++; > } > > void run () > { > interface = new pcl::OpenNIGrabber(); > w = new pcl::PCDWriter; > counter = 0; > > boost::function<void (const > pcl::PointCloud<pcl::PointXYZRGBA>::ConstPtr&)> f = > boost::bind (&testGrabber::cloud_cb_, this, _1); > > interface->registerCallback (f); > > interface->start (); > > while (true) > { > sleep (1); > } > > interface->stop (); > } > > // vs10 missing to_string(int) workaround > long long counter; > pcl::PCDWriter* w; > pcl::Grabber* interface; > > > }; > > > > //======================================================================== > int main( ){ > > testGrabber t; > t.run(); > > } > > -- > View this message in context: http://www.pcl-users.org/writeBinaryCompressed-too-slow-tp3840585p3842451.html > Sent from the Point Cloud Library (PCL) Users mailing list archive at Nabble.com. > _______________________________________________ > [hidden email] / http://pointclouds.org > http://pointclouds.org/mailman/listinfo/pcl-users _______________________________________________ [hidden email] / http://pointclouds.org http://pointclouds.org/mailman/listinfo/pcl-users |
|
Administrator
|
In reply to this post by Christoph Pacher
Christoph,
This is great feedback, thanks! On 03/20/2012 07:00 AM, Christoph Pacher wrote: > this is the list of the files the openni_grab_frame tool has written: [...] > > > > I also made a small grab test project with just PCL writing the files > without the OpenFrameworks app. when writing XYZRGBA files i get a callback > runtime between 40 and 50 ms, which is still too slow Ok, we're getting a bit closer. Our aim is 33ms here. Let's see... Can we eliminate the obvious things first? * compiled in Release mode with all the optimizations? * check if there's any issues with the filesystem or any other things running in the background that might affect the performance? * tried on a different machine? The next thing is to go inside the code so we can start timing what parts take the longest: is the compression itself, or the I/O part, etc. Thanks in advance for helping! Cheers, Radu. > > class testGrabber > { > public: > testGrabber (){} > > void cloud_cb_ (const pcl::PointCloud<pcl::PointXYZRGBA>::ConstPtr &cloud) > { > pcl::ScopeTime t ("grabber"); > > w->writeBinaryCompressed(std::to_string(counter) + ".pcd", *cloud); > counter++; > } > > void run () > { > interface = new pcl::OpenNIGrabber(); > w = new pcl::PCDWriter; > counter = 0; > > boost::function<void (const > pcl::PointCloud<pcl::PointXYZRGBA>::ConstPtr&)> f = > boost::bind (&testGrabber::cloud_cb_, this, _1); > > interface->registerCallback (f); > > interface->start (); > > while (true) > { > sleep (1); > } > > interface->stop (); > } > > // vs10 missing to_string(int) workaround > long long counter; > pcl::PCDWriter* w; > pcl::Grabber* interface; > > > }; > > > > //======================================================================== > int main( ){ > > testGrabber t; > t.run(); > > } > > -- > View this message in context: http://www.pcl-users.org/writeBinaryCompressed-too-slow-tp3840585p3842451.html > Sent from the Point Cloud Library (PCL) Users mailing list archive at Nabble.com. > _______________________________________________ > [hidden email] / http://pointclouds.org > http://pointclouds.org/mailman/listinfo/pcl-users [hidden email] / http://pointclouds.org http://pointclouds.org/mailman/listinfo/pcl-users |
|
I did a fresh install of Win7 a few days ago. There is not much installed on this machine except office and adobe products.
The project is compiled as release and with /Ox /Oi and /Ot flags. Are there any other opitmizations? Just did another test run with my Anitvirus off, no change in speed. Sorry I do not have another machine, except a netbook.... not really worth it trying on this one. I never did a performance profile in VS10 can you recommend a tutorial? |
The following tutorial should give you a brief introduction into the VS profiler: http://msdn.microsoft.com/en-us/magazine/cc337887.aspx The tutorial is originally for VS08, but it should be the same for VS10. |
|
i tried to profile the grab frame tool. unfortunately the release profiling results are not really helpful, as you cant see the code in question, only the dlls. see the result in the following image:
http://imageshack.us/photo/my-images/17/performanced.jpg/ |
|
Any news on this topic? Should I test something else?
|
|
Administrator
|
Christoph,
Sorry for the late reply - been busy. ;) Unfortunately the profiling graph you sent is not really helpful, so we would need to investigate this issue here in-house. It might take a few extra days though as we're swamped with other projects at the moment. Cheers, Radu. -- http://pointclouds.org On 03/27/2012 02:58 AM, Christoph Pacher wrote: > Any news on this topic? Should I test something else? > > > Christoph Pacher wrote >> >> i tried to profile the grab frame tool. unfortunately the release >> profiling results are not really helpful, as you cant see the code in >> question, only the dlls. see the result in the following image: >> >> http://imageshack.us/photo/my-images/17/performanced.jpg/ >> > > > -- > View this message in context: http://www.pcl-users.org/writeBinaryCompressed-too-slow-tp3840585p3860882.html > Sent from the Point Cloud Library (PCL) Users mailing list archive at Nabble.com. > _______________________________________________ > [hidden email] / http://pointclouds.org > http://pointclouds.org/mailman/listinfo/pcl-users [hidden email] / http://pointclouds.org http://pointclouds.org/mailman/listinfo/pcl-users |
|
I'm sorry for posting on such an old thread, but I too am having the same issue. I'm running pcl-trunk (1.7) on revision 7754. To rule out disk write performance, I ran the following benchmark:
dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output Which returned me 75MB/s in one platform and 90MB/s in another. Strangely, the first one (specs here) would only reach around 10fps, while the second (a core i5 desktop) had an average of 15fps. Both are Linux based and the data was being written by openni_grab_frame to ext4 partitions. In another platform (with 109MB/s of disk write performance and PCL 1.7 rev 7754), I decided to perform a test that would generate random clouds and save them with writeBinaryCompressed. Sice their average size was of 3.7MB, I shouldn't expect my system to reach 30fps (that would require a throughput of around 112MB/s), but I suppose it could reach around 27fps (100MB/s). Instead, I got an average of 11fps. So I decided to run gprof on this application, I'm uploading the resulting profile here. (The testGrabber::fill function was created for generating random point clouds, and is not directly affecting the writer performance). I hope this will give a hint and help optimize this function further. |
|
Administrator
|
Thanks - can you please open up a bug report at http://dev.pointclouds.org with a minimal code snippet that you used to
test this? Cheers, Radu. -- http://openperception.org On 11/01/2012 07:21 AM, csantos wrote: > I'm sorry for posting on such an old thread, but I too am having the same > issue. I'm running pcl-trunk (1.7) on revision 7754. To rule out disk write > performance, I ran the following benchmark: > > dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output > > Which returned me 75MB/s in one platform and 90MB/s in another. Strangely, > the first one (specs here > <http://www.notebookreview.com/default.asp?newsID=6047&review=msi+gx660+gx660r> > ) would only reach around 10fps, while the second (a core i5 desktop) had an > average of 15fps. Both are Linux based and the data was being written by > openni_grab_frame to ext4 partitions. > > In another platform (with 109MB/s of disk write performance and PCL 1.7 rev > 7754), I decided to perform a test that would generate random clouds and > save them with writeBinaryCompressed. Sice their average size was of 3.7MB, > I shouldn't expect my system to reach 30fps (that would require a throughput > of around 112MB/s), but I suppose it could reach around 27fps (100MB/s). > Instead, I got an average of 11fps. So I decided to run gprof on this > application, I'm uploading the resulting profile here > <http://www.pcl-users.org/file/n4023508/profile> . (The testGrabber::fill > function was created for generating random point clouds, and is not directly > affecting the writer performance). > > I hope this will give a hint and help optimize this function further. > > > > -- > View this message in context: http://www.pcl-users.org/writeBinaryCompressed-too-slow-tp3840585p4023508.html > Sent from the Point Cloud Library (PCL) Users mailing list mailing list archive at Nabble.com. > _______________________________________________ > [hidden email] / http://pointclouds.org > http://pointclouds.org/mailman/listinfo/pcl-users > [hidden email] / http://pointclouds.org http://pointclouds.org/mailman/listinfo/pcl-users |
| Powered by Nabble | Edit this page |
