Remove colour attributes from body and strip most of the font tags out
This commit is contained in:
James Gregory
parent
7e957c0bb4
commit
c1f88ddb41
362 changed files with 1632 additions and 1706 deletions
13
05-01.html
13
05-01.html
|
|
@ -24,7 +24,7 @@
|
|||
<!--CHAPTER=05//-->
|
||||
<!--PAGES=111-115//-->
|
||||
<!--UNASSIGNED1//-->
|
||||
<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
|
||||
<!--UNASSIGNED2//--></HEAD><body>
|
||||
|
||||
<CENTER>
|
||||
<TABLE BORDER>
|
||||
|
|
@ -36,9 +36,8 @@
|
|||
</TABLE>
|
||||
</CENTER>
|
||||
<P><BR></P>
|
||||
<H2><A NAME="Heading1"></A><FONT COLOR="#000077">Chapter 5<BR>Crossing the Border
|
||||
</FONT></H2>
|
||||
<H3><A NAME="Heading2"></A><FONT COLOR="#000077">Searching Files with Restartable Blocks</FONT></H3>
|
||||
<H2><A NAME="Heading1"></A>Chapter 5<BR>Crossing the Border</H2>
|
||||
<H3><A NAME="Heading2"></A>Searching Files with Restartable Blocks</H3>
|
||||
<P><I>We just moved.</I> Those three little words should strike terror into the heart of anyone who owns more than a sleeping bag and a toothbrush. Our last move was the usual zoo—and then some. Because the distance from the old house to the new was only five miles, we used cars to move everything smaller than a washing machine. We have a sizable household—cats, dogs, kids, com, you name it—so the moving process took a number of car trips. A <I>large</I> number—33, to be exact. I personally spent about 15 hours just driving back and forth between the two houses. The move took days to complete.</P>
|
||||
<P><I>Never again</I>.</P>
|
||||
<P>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 because it <I>seemed</I> easier and cheaper to use cars—no big truck to drive, no rentals, spread the work out more manageably, and so on.</P>
|
||||
|
|
@ -50,13 +49,13 @@
|
|||
</TABLE>
|
||||
<P>And with that, let’s look at a fairly complex application of restartable blocks.
|
||||
</P>
|
||||
<H4 ALIGN="LEFT"><A NAME="Heading3"></A><FONT COLOR="#000077">Searching for Text</FONT></H4>
|
||||
<H4 ALIGN="LEFT"><A NAME="Heading3"></A>Searching for Text</H4>
|
||||
<P>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 <B>argv</B>, it can’t contain any whitespace characters.)</P>
|
||||
<P>This is a <I>very</I> limited subset of what search utilities such as grep 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, like searching through a user-selectable file set.</P>
|
||||
<P>The first point to address in designing our program involves the appropriate text-search approach to use. Literally dozens of workable ways exist to search a file. We can immediately discard all approaches 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 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 be between 16K and 64K, depending on the exact search approach, 64K being the maximum size because near pointers make for superior performance.</P>
|
||||
<P>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?</P>
|
||||
<P>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 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).</P>
|
||||
<H3><A NAME="Heading4"></A><FONT COLOR="#000077">Avoiding the String Trap</FONT></H3>
|
||||
<H3><A NAME="Heading4"></A>Avoiding the String Trap</H3>
|
||||
<P>The easiest approach would be to use a C/C<SMALL>++</SMALL> library function. The closest match to what we need is <B>strstr()</B>, which searches one string for the first occurrence of a second string. However, while <B>strstr()</B> 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, <B>strstr()</B> searches a <I>string</I> for the first occurrence of another string.</P><P><BR></P>
|
||||
<CENTER>
|
||||
<TABLE BORDER>
|
||||
|
|
@ -70,7 +69,7 @@
|
|||
|
||||
<hr width="90%" size="1" noshade>
|
||||
<div align="center">
|
||||
<font face="Verdana,sans-serif" size="1">Graphics Programming Black Book © 2001 Michael Abrash</font>
|
||||
Graphics Programming Black Book © 2001 Michael Abrash
|
||||
</div>
|
||||
<!-- all of the reference materials (books) have the footer and subfoot reveresed -->
|
||||
<!-- reference_subfoot = footer -->
|
||||
|
|
|
|||
Loading…
Reference in a new issue