Hi, On 9 July 2017 at 10:52, Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> wrote: > On Sun, Jul 09, 2017 at 01:25:36AM -0700, Christopher Li wrote: >> For the record, I did run your code with kernel source checking. >> "wasn't anything significative" by itself was not good enough to >> accept the patch. Such a big rewrite of such fundamental building >> block better have good enough reason for it. I don't see a lot >> of up side to justify it. I definitely see the down side in performance. > > And what was this slow down you saw? 5%, 1%, less than 1%? > It would help to have some number. Like I said above, when > I did the test any speed difference I saw was within the > noise. > As I am using a function based iterator in dmr_C this discussion is of interest. I agree with Luc that micro benchmarks are not very useful. Is there data on what the performance impact is on running sparse against say the Linux kernel. Is there statistically significant difference? I personally think that the trade-off for more understandable and supportable code here is worth it as really the performance difference if extremely small should not be of great importance to a tool like sparse which is a development tool, and not something you are running to handle production workload. My approach in dmr_C allows me to switch between the macro based implementation and the function based implementation, primarily so that when I get failures I can check if the failures are due to the changes I made. But this has the drawback of maintaining two versions. Anyway just wanted to put my vote for the changes proposed by Luc. Regards Dibyendu -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
