Curious about corner case in btrfs code

[Valdis.Kletnieks at vt.edu]

On Tue, 26 Aug 2014 18:47:41 -0400, Nick said:
> After reading through the code in inode.c today , I am curious about the comment and the following code I will paste
> below. I am curious if this corner case is hit often enough for me to write a patch to improve the speed of this
> corner case.

    421         if (actual_end <= start)
    422                 goto cleanup_and_bail_uncompressed;

Wow, that's a heck of a small optimization target. How to approach it?

Step 3: Become proficient enough to instrument the code and actually measure it.
Because upstream will never accept a patch optimizing a "corner case" unless
you have actual numbers that show an actual improvement under production
workloads as opposed to microbenchmarks.

Step 2: Read the code, and ask yourself how the hell you intend to make the
code any faster than the relatively cheap if/goto that's currently in place.
Note that the combination of superscalar and speculative execution on modern
processors and good optimizing compilers means that it's possible that the 2
lines of code will execute in effectively *zero* cycles.  Hard to make it
faster than that. :)

Step 1: Note that the zero-cycles branch is in a loop that includes a
call to btrfs_compress_pages(), which is going to take *at least* 4096
cycles to process a 4K page (simply because you have to look at each byte
in the buffer at least once).  So the percentage savings is pretty low here,
because it's swamped by calls to compress and memset and other stuff that
chews a lot more cycles.

Step 0: Ask yourself how often programs either *ignore* an EOF condition
on a file they are reading, and keep trying to read past the end of the file,
or do an explicit lseek()/read() beyond the end of the file, and whether it's
worth optimizing that case at the expense of making the code more complex and
probalby slower in the non-corner-case case.

The tl;dr:  You're barking up the wrong tree here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140826/21cbdc00/attachment.bin