Hello, author here. Just to clarify, I wasn't saying that this has any perf impact per se. I was trying to see why syscall showed up quite a bit in the profile, when reading a large file, no matter what buffer size I pass in. Rather than spend time finishing the actual work, I spent way too much time trying to understand the reason for the limit.

Author here. I wasn't suggesting it would have any perf impact. Just that it was an interesting change set.

I feel I'm missing something here, but it feels like the intro is not only suggesting there was a performance impact, but very explicitly stating there was:

> profile of a sample word count program I was writing, which showed the program was spending way too much time in the syscall module. That in this context can only mean one thing: way too many read syscalls were getting called.

I find it hard to believe that the profile would look any different with 1 vs 2 syscalls per 2GB chunk. The syscall overhead is going to be insignificant compared to actually copying the data. The program is going to be spending a lot of time doing syscalls no matter how many there are, because the individual syscalls will just start to take more time as you increase the size of the buffer.

Edit:

Compare:

  strace -e read -T perl -MFcntl -e 'sysopen FD, "foo", Fcntl::O_RDONLY; while (sysread FD, $buf, 1*1024*1024*1024) {} '

  read(3, ..., 1073741824) = 1073741824 <0.455901>
  read(3, ..., 1073741824) = 1073741824 <0.219711>
  read(3, ..., 1073741824) = 1073741824 <0.213923>
  read(3, ..., 1073741824) = 1073741824 <0.211783>

Vs.

  strace -e read -T perl -MFcntl -e 'sysopen FD, "foo", Fcntl::O_RDONLY; while (sysread FD, $buf, 2*1024*1024*1024) {} '

  read(3, ..., 2147483648) = 2147479552 <0.921789>
  read(3, ..., 2147483648) = 2147479552 <0.487007>
  read(3, ..., 2147483648) = 8192 <0.000031>

I tried your strace commands on my linux desktop and I don't get anything like your results. I get a few lines of 'read(3, "\177ELF\2\1\1...' type stuff. Are you using bash (as I am) or some other shell? Could there be some escaping that I'm missing? Thanks.

It's reading from a file named foo, which in this case was 4GB large and created with:

  dd if=/dev/zero of=foo bs=1024 count=$((1024*1024*4))

You probably don't have a file of that name in the current working directory?

I missed that, thanks.

Makes sense, I guess I misunderstood the premise of the article. It's a good dive.

Indeed! I should’ve dropped some of these screenshots or links to FF devtools in the post.

Thanks! As for the images, I drew them in Sketch.

Wow, this is cool!

Hey, thanks! I intentionally left out all the other ones. This was a deliberate reductionist view of the feature.

Logo "designer" here. That's an uncanny, unfortunate resemblance. All those hours taking pictures of a paper boat to redraw it seem so wasteful now :'|

FWIW, Typekit has an async loader script that doesn't block the rendering. Same is the case with Google web fonts. Both services use the open source WebFontLoader[1] library behind the scenes (which is mentioned in the article).

Typekit has a feature they call language subsetting which reduces the file size of a particular typeface family by removing language support based on user selection. This can reduce font sizes quite a bit.

>Google Fonts doesn't use any JavaScript (by default, anyway), which makes it faster than almost any JavaScript-enabled approach

This involves a stylesheet which means the rendering is blocked until it is downloaded and processed and the users will see a page with blank text until that happens. Sometimes it is better to show the content (even in a fallback font) instead of a blank page.

1: https://github.com/typekit/webfontloader