Misc/abrash-black-book
Watch
1
0
Fork
You've already forked abrash-black-book
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Normal quotes

Browse source
This commit is contained in:
James Gregory 2013-12-30 18:34:31 +11:00
commit 18011c595a
352 changed files with 6040 additions and 6040 deletions
Download patch file Download diff file Expand all files Collapse all files

36
05-01.md
View file

@ -20,17 +20,17 @@ The move took days to complete.
*Never again*.
You’re probably wondering two things: What does this have to do with
high-performance programming, and why on earth didn’t I rent a truck and
You're probably wondering two things: What does this have to do with
high-performance programming, and why on earth didn't I rent a truck and
get the move over in one or two trips, saving hours of driving? As it
happens, the second question answers the first. I didn’t rent a truck
happens, the second question answers the first. I didn't rent a truck
because it *seemed* easier and cheaper to use cars—no big truck to
drive, no rentals, spread the work out more manageably, and so on.
It wasn’t easier, and wasn’t even much cheaper. (It costs quite a bit to
It wasn't easier, and wasn't even much cheaper. (It costs quite a bit to
drive a car 330 miles, to say nothing of the value of 15 hours of my
time.) But, at the time, it seemed as though my approach would be easier
and cheaper. In fact, I didn’t realize just how much time I had wasted
and cheaper. In fact, I didn't realize just how much time I had wasted
driving back and forth until I sat down to write this chapter.
In Chapter 1, I briefly discussed using *restartable blocks*. This, you
@ -55,24 +55,24 @@ more effort and forethought, but would have paid off handsomely.
![](images/i.jpg) *The easy, familiar approach often has nothing in its favor except that it requires less thinking; not a great virtue when writing high-performance code—or when moving.*
------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
And with that, let’s look at a fairly complex application of restartable
And with that, let's look at a fairly complex application of restartable
blocks.
#### Searching for Text {#Heading3}
The application we’re going to examine searches a file for a specified
string. We’ll develop a program that will search the file specified on
The application we're going to examine searches a file for a specified
string. We'll develop a program that will search the file specified on
the command line for a string (also specified on the comline), then
report whether the string was found or not. (Because the searched-for
string is obtained via **argv**, it can’t contain any whitespace
string is obtained via **argv**, it can't contain any whitespace
characters.)
This is a *very* limited subset of what search utilities such as grep
can do, and isn’t really intended to be a generally useful application;
can do, and isn't really intended to be a generally useful application;
the purpose is to provide insight into restartable blocks in particular
and optimization in general in the course of developing a search engine.
That search engine will, however, be easy to plug into any program, and
there’s nothing preventing you from using it in a more fruitful context,
there's nothing preventing you from using it in a more fruitful context,
like searching through a user-selectable file set.
The first point to address in designing our program involves the
@ -82,9 +82,9 @@ that involve reading any byte of the file more than once, because disk
access time is orders of magnitude slower than any data handling
performed by our own code. Based on our experience in Chapter 1, we can
also discard all approaches that get bytes either one at a time or in
small sets from DOS. We want to read big “buffers-full” of bytes at a
small sets from DOS. We want to read big "buffers-full" of bytes at a
pop from the searched file, and the bigger the buffer the better—in
order to minimize DOS’s overhead. A good rough cut is a buffer that will
order to minimize DOS's overhead. A good rough cut is a buffer that will
be between 16K and 64K, depending on the exact search approach, 64K
being the maximum size because near pointers make for superior
performance.
@ -93,13 +93,13 @@ So we know we want to work with a large buffer, filling it as
infrequently as possible. Now we have to figure out how to search
through a file by loading it into that large buffer in chunks. To
accomplish this, we have to know how we want to do our searching, and
that’s not immediately obvious. Where do we begin?
that's not immediately obvious. Where do we begin?
Well, it might be instructive to consider how we would search if our
search involved only one buffer, already resident in memory. In other
words, suppose we don’t have to bother with file handling at all, and
further suppose that we don’t have to deal with searching through
multiple blocks. After all, that’s a good description of the
words, suppose we don't have to bother with file handling at all, and
further suppose that we don't have to deal with searching through
multiple blocks. After all, that's a good description of the
all-important inner loop of our searching program, where the program
will spend virtually all of its time (aside from the unavoidable disk
access overhead).
@ -109,7 +109,7 @@ access overhead).
The easiest approach would be to use a C/C++ library function. The
closest match to what we need is **strstr()**, which searches one string
for the first occurrence of a second string. However, while **strstr()**
would work, it isn’t ideal for our purposes. The problem is this: Where
would work, it isn't ideal for our purposes. The problem is this: Where
we want to search a fixed-length buffer for the first occurrence of a
string, **strstr()** searches a *string* for the first occurrence of
another string.