Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > > but I confess to being a little ambivalent. It's > > arguably a little easier to read, > > I have another opinion here. Instead of parsing body of for-loop, the name of > the function tells you exactly what it's done. Besides the fact that reading > and parsing two lines, with zero conditionals, is faster. > > > but it's not nearly as efficient > > (not a great concern here) > > David, do you know why for_each_set_bit() has no optimization for the cases > when nbits <= BITS_PER_LONG? (Actually find_*bit() family of functions) I've not had anything to do with for_each_set_bit() itself. By 'nbits', I presume you mean the size parameter - max in the sample bit of code. It would need per-arch optimisation. Some arches have an instruction to find the next bit and some don't. Using for_each_set_bit() like this is definitely suboptimal, since find_first_bit() and find_next_bit() may well be out of line. It should probably be using something like __ffs() if size <= BITS_PER_LONG. David
