Change bold code snippets to inline code blocks
This commit is contained in:
parent
f658bfbb40
commit
3c76d884ef
185 changed files with 1772 additions and 1772 deletions
10
01-04.md
10
01-04.md
|
|
@ -93,15 +93,15 @@ approaches.
|
|||
|
||||
Listing 1.4 is good, but let's see if there are other—perhaps less
|
||||
obvious—ways to get the same results faster. Let's start by considering
|
||||
why Listing 1.4 is so much better than Listing 1.1. Like **read()**,
|
||||
**getc()** calls DOS to read from the file; the speed improvement of
|
||||
Listing 1.4 over Listing 1.1 occurs because **getc()** eads many bytes
|
||||
why Listing 1.4 is so much better than Listing 1.1. Like `read()`,
|
||||
`getc()` calls DOS to read from the file; the speed improvement of
|
||||
Listing 1.4 over Listing 1.1 occurs because `getc()` eads many bytes
|
||||
at once via DOS, then manages those bytes for us. That's faster than
|
||||
reading them one at a time using **read()**—but there's no reason to
|
||||
reading them one at a time using `read()`—but there's no reason to
|
||||
think that it's faster than having our program read and manage blocks
|
||||
itself. Easier, yes, but not faster.
|
||||
|
||||
Consider this: Every invocation of **getc()** involves pushing a
|
||||
Consider this: Every invocation of `getc()` involves pushing a
|
||||
parameter, executing a call to the C library function, getting the
|
||||
parameter (in the C library code), looking up information about the
|
||||
desired stream, unbuffering the next byte from the stream, and returning
|
||||
|
|
|
|||
Loading…
Reference in a new issue