- static vector (c style) - 3 Updates
| Juha Nieminen <nospam@thanks.invalid>: Jan 21 11:08AM > always much slower than virtual functions." > It is also logical. Otherwise compiler would generate for (at least some of) > virtual calls such switch-cases under the hood. It depends on what the values of the cases are in the switch block. If they are appropriate, most compilers will generate a jump table instead of just a chain of conditionals. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Martijn Lievaart <m@rtij.nl.invlalid>: Jan 21 08:26PM +0100 On Tue, 20 Jan 2015 20:52:36 +0000, Scott Lurndal wrote: >>)=20 virtual calls such switch-cases under the hood. > I'm afraid it is difficult to take your word for this without any data > to support it. Thanks for the support. > different cacheline to access the vtbl for the object which, depending > on residency in the LLC, may result in a delay of between 80 and 400 > instructions to fill. This is one important case where virtual functions can be (much) slower. Another one is when the cost of the virtual destructor offsets the gains from the virtual function. Common in designs where many small objects get allocated and destructed frequently. There probably are many other scenarios where virtual functions are not faster than the alternatives. Do understand that I advocate using virtual functions where they are appropriate. Only when virtual functions really seem to be the bottleneck (so after deciding that it really is not fast enough, and after any algorithmic gains, and after any other quick performance wins, and after optimizing IO patterns, and after ...) only then it MAY be worthwhile to think about whether virtual functions are the problem or the solution. M4 |
| "Öö Tiib" <ootiib@hot.ee>: Jan 21 01:10PM -0800 On Wednesday, 21 January 2015 21:30:30 UTC+2, Martijn Lievaart wrote: > Another one is when the cost of the virtual destructor offsets the gains > from the virtual function. Common in designs where many small objects get > allocated and destructed frequently. On that case the performance bottle-neck has always been (in my tests) that dynamic memory management itself, not the virtual functions (or destructors). Memory managers are improved over time but their work is still way slower than additional indirection from virtual call. > gains, and after any other quick performance wins, and after optimizing > IO patterns, and after ...) only then it MAY be worthwhile to think about > whether virtual functions are the problem or the solution. Do understand me too, I am not saying that all switch-cases or if-else-if chains can be replaced with dynamic polymorphism. However some that I have seen were originally written instead of virtuals (or had grown over time into replacement of virtuals) and virtuals did improve performance on such cases in my tests. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment