C++ footprint and performance optimization 2000

C++FootprintandPerformance
Optimization
ByR.Alexander,G.Bensley


Publisher :SamsPublishing
PubDate :September20,2000
ISBN
:0-672-31904-7
Pages
:400
Themarketforminiaturecomputer
programmingisexploding.C++Footprintand
PerformanceOptimizationsupplies
programmerstheknowledgetheyneedtowrite
codefortheincreasingnumberofhand-held
devices,wearablecomputers,andintelligent
appliances.



Thisbookgivesreadersvaluableknowledge
andprogrammingtechniquesthatarenot
currentlypartoftraditionalprogramming
training.


Tableof
•
Contents

• Index

IntheworldofC++programming,allother
thingsbeingequal,programsthataresmaller
andfasterarebetter.
C++FootprintandPerformanceOptimization
containscasestudiesandsamplecodetogive
readersconcreteexamplesandproven
solutionstoproblemsthatdon'thavecutand
pastesolutions.

EEn
777








Copyright



AbouttheAuthors



Acknowledgments

TellUsWhatYouThink!



Introduction:WhyOptimize?



AimofThisBook



WhoThisBookIsFor



TheStructureofThisBook



PartI:EverythingButtheCode

Chapter1.Optimizing:WhatIsItAllAbout?
Performance





Footprint





Summary










Chapter2.CreatingaNewSystem
SystemRequirements

SystemDesignIssues





TheDevelopmentProcess





DataProcessingMethods





Summary

Chapter3.ModifyinganExistingSystem
IdentifyingWhattoModify





BeginningYourOptimization





AnalyzingTargetAreas





PerformingtheOptimizations





Summary

PartII:GettingOurHandsDirty





Chapter4.ToolsandLanguages





ToolsYouCannotDoWithout





OptimizingwithHelpfromtheCompiler





TheLanguagefortheJob

Summary










Chapter5.MeasuringTimeandComplexity
TheMarriageofTheoryandPractice





SystemInfluences





Summary

Chapter6.TheStandardC/C++Variables
VariableBaseTypes





GroupingBaseTypes





Summary

Chapter7.BasicProgrammingStatements
Selectors





Loops





Summary






Chapter8.Functions

InvokingFunctions





PassingDatatoFunctions





EarlyReturns





FunctionsasClassMethods





Summary

Chapter9.EfficientMemoryManagement





MemoryFragmentation





MemoryManagement





ResizableDataStructures





Summary

Chapter10.BlocksofData
ComparingBlocksofData





TheTheoryofSortingData





SortingTechniques





Summary

Chapter11.StorageStructures





Arrays





LinkedLists





HashTables





BinaryTrees

Red/BlackTrees





Summary






Chapter12.OptimizingIO





EfficientScreenOutput





EfficientBinaryFileIO

EfficientTextFileIO





Summary










ArithmeticOperations





OperatingSystem–BasedOptimizations

Summary




Chapter13.OptimizingYourCodeFurther




PartIII:TipsandPitfalls









Chapter14.Tips
Tricks





PreparingfortheFuture

Chapter15.Pitfalls





AlgorithmicPitfalls





TyposthatCompile





OtherPitfalls

Index


Copyright
Copyright©2000bySamsPublishing
Allrightsreserved.Nopartofthisbookshallbereproduced,storedina
retrievalsystem,ortransmittedbyanymeans,electronic,mechanical,
photocopying,recording,orotherwise,withoutwrittenpermissionfrom
thepublisher.Nopatentliabilityisassumedwithrespecttotheuseofthe
informationcontainedherein.Althougheveryprecautionhasbeentaken
inthepreparationofthisbook,thepublisherandauthorsassumeno
responsibilityforerrorsoromissions.Norisanyliabilityassumedfor
damagesresultingfromtheuseoftheinformationcontainedherein.
LibraryofCongressCatalogCardNumber:99-068917
PrintedintheUnitedStatesofAmerica
FirstPrinting:September,2000
0201004321

Trademarks
Alltermsmentionedinthisbookthatareknowntobetrademarksor
servicemarkshavebeenappropriatelycapitalized.Samscannotattestto
theaccuracyofthisinformation.Useofaterminthisbookshouldnotbe
regardedasaffectingthevalidityofanytrademarkorservicemark.

WarningandDisclaimer
Everyefforthasbeenmadetomakethisbookascompleteandas
accurateaspossible,butnowarrantyorfitnessisimplied.The
informationprovidedisonan"asis"basis.Theauthorsandthepublisher
shallhaveneitherliabilitynorresponsibilitytoanypersonorentitywith
respecttoanylossordamagesarisingfromtheinformationcontainedin

thisbookorfromtheuseoftheWebsiteorprogramsaccompanyingit.
Publisher
MichaelStephens
AcquisitionsEditor
WilliamE.Brown
DevelopmentEditors
TonyAmico
BeverlyScherf
ManagingEditor
MattPurcell
ProjectEditor
NatalieF.Harris
CopyEditors
MichaelDietsch
AndrewSimmons
Indexer
SandraHenselmeier
Proofreaders
PatKinyon
TonyReitz


MattWynalda
TechnicalEditor
GregGuntle
TeamCoordinator
PamaleeNelson
MediaDeveloper

DanScherf
InteriorDesigners
GaryAdair
AnneJones
CoverDesigner
AnneJones
Production
DarinCrone

Dedication
ToOlivera,Tjitske,andLeanne,whosomehowfoundtherestrainttonot
killus.


AbouttheAuthors
Astheauthorsofthebookyouareabouttoread,wewouldliketo
introduceourselves.Withmorethan10yearsofprofessionalIT
experiencebetweenus,wehaveworkedonvastlydifferentprojectsfor
differentcompanies.Oneofusiscurrentlyinvolvedindesigningtimecriticalembeddedsoftware,theotherisworkingonInternetandsatellitetransmissionsoftwarefordigitalvideocommunications.
Inoursparetimewehavebeenworkingonaprojectwhichinvolved
developingadvancedtechniquesforoptimizingC/C++codeforspeed
andsize.Wefoundthatwhileworkingonprofessionalsoftware,the
samekindsofproblemsandpitfallskeptarising,whetherduring
developmentofembeddedsoftwareorevendesktopapplications.It
seemedtousthatadeeperunderstandingoftheseproblemscouldnot
onlyaidinwritingbettersoftware,butalsobeofgreatassistanceduring
faultsolving.Thatiswhywedecidedthattheresultofourprojectshould
beatutorialinwhichweshareourfindingsofpracticalproblemsandthe
solutionsweused,aswellasourtheoriesonoptimizingsoftware.
Thebookyouareholdingnowisinfactonethatwe,andmanyofour

colleagues,havebeenlookingforsincewestartedintheITbusiness.
R.Alexander
G.Bensley


Acknowledgments
WewouldliketothankthepeopleatSamsforrecognizingthevalueof
thisprojectandhelpingusdevelopitintothebookyouarenowholding.
Specialthanksgotothoseonthehomefrontwhohadtoendureour
absenceandmorethantheirfairshareofdutiesaroundthehouse.


TellUsWhatYouThink!
Asthereaderofthisbook,youareourmostimportantcriticand
commentator.Wevalueyouropinionandwanttoknowwhatwe'redoing
right,whatwecoulddobetter,whatareasyou'dliketoseeuspublishin,
andanyotherwordsofwisdomyou'rewillingtopassourway.
AsaPublisherforSams,Iwelcomeyourcomments.Youcanfax,email,
orwritemedirectlytoletmeknowwhatyoudidordidn'tlikeaboutthis
book—aswellaswhatwecandotomakeourbooksstronger.
PleasenotethatIcannothelpyouwithtechnicalproblemsrelatedtothe
topicofthisbook,andthatduetothehighvolumeofmailIreceive,I
mightnotbeabletoreplytoeverymessage.
Whenyouwrite,pleasebesuretoincludethisbook'stitleandauthoras
wellasyournameandphoneorfaxnumber.Iwillcarefullyreviewyour
commentsandsharethemwiththeauthorandeditorswhoworkedon
thebook.
Fax:
Email:
Mail:

317-581-4770

MichaelStephens
Sams
201West.103rdStreet
Indianapolis,IN46290USA


Introduction:WhyOptimize?
Nowadays,softwareisvirtuallyeverywhere.Thoughyoumightinitially
thinkonlyofPCsandindustrialcomputersystemswhentalkingabout
software,applicationsaremuchmorewidespread.Considerwashing
machines,electricrazors,thermostats,microwaveovens,cars,TVs,
monitorsandsoon.Obviouslytheseexamplesspanmanydifferentkinds
ofarchitecturesanduseavarietyofmicroprocessors.Different
optimizationtechniquesforperformanceandfootprintsizeareneeded
here.
Evenanexaminationofthosewritingtoday'ssoftwarerevealsmuch
diversity.Thereisthegenerationofsoftwareimplementerswhowere
schooledspecificallyinwritingsoftware—thatis,doingrequirements
analysis,design,andimplementation.Therearealsothosewhotaught
themselvestowritesoftware,startingperhapsashobbyists.Andmore
andmoreweseepeoplefromdifferentdisciplinesswitchingtosoftware
writing.Thismeansthatitisnolongerafairassumptionthatall
programmershave,inessence,atechnicalbackground.
C/C++programmingcoursesandbooksgiveanexcellentintroductionto
theworldofC/C++programming.Basicallyaccessibleforallagesand
disciplines,theymakeitpossibleforanyonetowriteaworkingC/C++
program.However,standardtechniqueshavemanypitfallsand

inefficienciestoavoidwhenactivelydevelopingsoftware—beit
commerciallyorasahobby.Withoutcompletelyunderstandingthe
consequencesofprogrammingdecisionsonatechnicallevel,
implementersunwillinglycompromisethespeedandsizeofthesoftware
theywrite.
Thebasisforanefficientprogramislaidlongbeforeanyactualcodeis
written,whentherequirementsanddesignaremadeandthehardware
targetischosen.Andevenwhenthesoftwareiseventuallywritten,a
simplematterofsyntaxmightbeallthatseparatesthosewhoproduce
optimalexecutablecodefromthosewhodonot.Ifyouknowwhatto
write,youcaneasilyoptimizeyourcodetorunmanytimesmore
efficiently.Efficiencycanbeincreasedevenfurtherwithspecific


programmingtechniques,differinginlevelofskillrequiredfromthe
programmer


AimofThisBook
Asthetitlesuggests,theaimofthisbookistohelpthereaderoptimize
performanceandfootprintofsoftware.Regardlessofwhetherthereader
isasoftwarearchitect,animplementer,orevenaprojectleader,this
bookservesasatutorialtohelpthereaderacquireorenhancethe
followingessentialskills:
Analyzingwhereandwheninthedevelopmentprocessproblems
tendtoarise
Recognizingpitfallsofstandarddesignandprogrammingtechniques
ImprovingC/C++programmingskills
Gainingdetailedtechnicalinsightintoprogrammingtechniques
Learningusefulsolutionsandwhentousethem

Theseskillsformthebasisforcreatingefficientsoftware.Thisbook
guidesevenbeginningprogrammersintousingtheadvancedtechniques
offeredhereforwritingbettersoftware.Moreexperiencedprogrammers
cangetgoingrightawaywiththeadvancedtopicsandwillalsofindthis
booktobeahelpfulrepositoryofallthedo'sanddon'tstheyhaveto
continuallykeepaheadof.Themanyhints,insights,andexamplesgiven
onthedevelopmentprocesswillalsobeofusetoprojectleadersand
architects.


WhoThisBookIsFor
Thisbookstartswithseveralchaptersonoptimizationtheoryandthen
introducestechnicalsubjectmatterandexampleswithincreasing
complexity.Thismeansthatbeginningprogrammerscanusethisbook
asatutorialtoguidethemintooptimizingtechniques,andmore
experiencedprogrammerscangothroughtothemorecomplexsubjects
atafasterpace.Readersnotdirectlyinvolvedwithactualprogram
implementation,suchasprojectleadersorarchitects,canstillbenefit
fromfamiliarizingthemselveswiththeconceptsdiscussedinthefirstpart
ofthebookandseveral"pitfall"and"tips"sectionsoflaterchapters.The
manyexamplesofproblemsandsolutionsactuallyencounteredinthe
field,whichareusedthroughoutthisbook,willbeusefultoanyonewith
software-relatedinterests.


TheStructureofThisBook
Thisbookisdividedintothreedistinctparts.
PartI,"EverythingButtheCode"(Chapters1–3)—Thisfirstbook
partdiscussesoptimizationtheoryoftheaspectsofsoftware
developmentthatprecedeactualimplementation.Itoffersadvice

andpracticalexampleswithsolutionsinareassuchaschoosing
betweenprogramminglanguages,examiningtargethardware,
lookingatdeviceinteraction,settingupcorrectsystemrequirements,
designingnewsystems,andoptimizingsystemsthatalreadysuffer
fromperformanceproblems.
PartII,"GettingOurHandsDirty"(Chapters4–13)—Thissecond
bookpartdiscussesimplementationproblemareasbylookingat
examplesofproblemsoftenencounteredinthefield.Itshowswhere
andwhyproblemsarelikelytooccurandoffersready-to-use
solutionsforefficientfunctioncalling,memorymanagement,IO,and
settingupandhandlingdatastructures.
PartIII,"TipsandPitfalls"(Chapters14and15)—Thisthirdbookpart
givesanoverviewofsneakyproblemsandtrapsyoucanencounter
whenusingC/C++.
Forthecodesamplesusedthroughoutthisbook,gototheWebsiteat
andsearchforthisbook'sISBN,
0672319047.



PartI:EverythingButtheCode
Thisfirstpartdiscussesoptimizationtheoryoftheaspectsof
softwaredevelopmentthatprecedeactualimplementation.Itoffers
adviceandpracticalexampleswithsolutionsinareassuchas
choosingbetweenprogramminglanguages,examiningtarget
hardware,lookingatdeviceinteraction,settingupcorrectsystem
requirements,designingnewsystems,andoptimizingsystemsthat
alreadysufferfromperformanceproblems.
1Optimizing:WhatIsItAllAbout?

2CreatingaNewSystem

3ModifyinganExistingSystem


CONTENTS


Chapter1.Optimizing:WhatIsItAll
About?
INTHISCHAPTER
Performance
Footprint
Thischapterprovidesanextensiveintroductiontooptimization.It
explainsthedefinitionsandjargonusedandclarifieswhyitisso
importanttoknowwhenandhowtooptimizesoftware.Oftentheterm
optimizationisassociatedwithperformanceenhancementsonly;
however,theamountofmemoryandotherresourcesanapplication
claimsisimportanttominimizealso.Bothperformanceandfootprint
optimizationsarediscussedinthischapter.

Performance
Thefirstpartofthischapterdiscussesoptimizationfromtheperformance
viewpoint.Herenotonlysoftwareandhardwarecharacteristicsare
discussed,butalsohowperformanceisperceivedbyusersofasystem.

WhatIsPerformance?
Whatdoesperformanceactuallymeaninrelationtosoftware?The
simpleansweristhatperformanceisanexpressionoftheamountof
workthatisdoneduringacertainperiodoftime.Themoreworka

programdoesperunitoftime,thebetteritsperformance.Putdifferently,
theperformanceofaprogramismeasuredbythenumberofinput(data)
unitsitmanagestotransformintooutput(data)unitsinagiventime.This
translatesdirectlyintothenumberofalgorithmicstepsthatneedtobe
takentocompletethistransformation.Forexample,analgorithmthat
executes10programstatementstostoreanameinadatabaseperforms


poorlycomparedtoonethatstoresthesamenameinfivestatements.
Similarly,adatabasesetupthatrequires20stepstobetakenbeforeit
knowswherenewdataistobeinsertedhasahigherimpactonprogram
performancethanadatabasesetupthatdoesthesamein10steps.But
therearemorethingstoconsiderthanpurelytechnicalimplications,
whichiswhatthissectionwillhighlight.
Ofthesoftwarethatiswrittentoday,averylargepartissetuptobeused
byoneormoreusersinteractively.Thinkofwordprocessors,project
managementtools,andpaintprograms.Theusersofthesekindsof
programsgenerallysitbehindtheircomputersandworkwithasingle
programuntiltheyhavecompletedacertaintask—forexample,planned
theactivitiesofasubordinate,drawnadiagram,orwrittenaransom
note.Solet'sexaminehowsuchauserdefinesperformance;afterall,in
mostcaseshewillbetheonewedotheoptimizationsfor.Basically,there
areonlythreesituationsinwhichauseractuallythinksintermsof
performanceatall:
Whenatasktakeslesstimethananticipatedbytheuser.
Whenatasktakesmoretimethananticipatedbytheuser.
Whenthesizeorcomplexityofthetaskisapparenttotheuser.
Examiningthesesituationscanprovidefurtherguidelinesfordefining
performance.Herefollowthreeexamplesthatillustratethebulletpoints:
Ataskcantakelesstimethananticipatedbytheuserwhen,forexample,

thisuserhasbeenworkingwiththesameprogramonthesame
computerforyearsandherbossfinallydecidestoupgradetonextgenerationmachines.Theuserisstillrunningthesameprogram,but
becausethehardwarecanexecuteitfaster,performanceseemstobe
better.Also,theuserhasbecomeaccustomedtoacertainkindof
behavior.Inthenewsituationherexpectationsareexceeded,sheno
longerhastotwiddleherthumbswhensavingalargefileorperforminga
complexcalculation.
Ataskcantakemoretimethananticipatedbytheuserwhen,for
example,thisuserworkswithaprogramthathandlesalargebaseof
sortednames.Onstartup,theprogramtakesabout15secondstoload


andsortitsdata,withoutgivingstatusupdates.Evenifitsalgorithmsare
highlyoptimized,theuserviewsthisunanticipated"delay"aspoor
softwareperformance.
Thesizeandcomplexityofataskcanbeapparenttotheuserwhen,for
example,theuserworkswithaprogramthatsearchesthrough
megabytesoftextfilestofindtheoccurrencesofacertainstring.This
actiontakesonlysecondsand,becauseofhertechnicalbackground,the
userknowswhatisinvolvedwiththisaction.Herperceptionofthe
performanceofthesearchprogramisthereforefavorable.
Theseexamplesdemonstratethatperformanceismorethanasimple
measureoftimeandprocessing.Performancefromtheviewpointofa
userismoreofafeelingshehasabouttheprogramthantheactual
workloadperseconditmanagestoprocess.Thisfeelingisinfluencedby
anumberoffactorsthatleadtothefollowingstatements:
Unexpectedandunexplainedwaitingtimeshaveanegativeeffecton
theperceivedperformance.
Performanceisacombinationofhardwareandsoftware.
Performancedependsonwhattheuserisaccustomedto.

Performancedependsonuser'sknowledgeofwhattheprogramis
doing.
Repetitionofatechnicallyefficientactionwillstillaffectperceived
performancenomatterhowknowledgeabletheuseris.

WhyOptimize?
Althoughoptimizationisalogicalchoiceforthosewhowritetime-critical
orreal-timeprograms,ithasmorewidespreaduses.Alltypesofsoftware
caninfactbenefitfromoptimization.Thissectionshowsfourreasons
why:
Asprogramsleavethedevelopmentenvironmentandareputtouse
inthefield,theamountsofdatatheyneedtohandlewillgrow


steadily.Thiseventuallyslowstheprogramdown,perhapsevento
thepointofitbeingunusable.
Carefullydesignedandimplementedprogramsareeasiertoextend
inthefuture.Considerthebenefitsofaddingfunctionalitytoan
existingprogramwithoutconcernaboutdegradingitsperformance
duetoproblemsintheexistingcode.
Workingwithafastprogramismorecomfortableforusers.Infact,
speedistypicallynotanissueuntilitslowsusersdown.
Timeismoney.
Atemptingquestionthatyouareboundtoasksoonerorlateris,Whynot
justbuyfasterhardware?Ifyoursoftwaredoesnotseemabletocutit
anymore,whynotsimplyupgradetoafasterprocessororusemoreor
fastermemory?Processingspeedtendstodoubleevery18months,so
algorithmsthatmighthaveposedaproblemsixmonthsorayearbefore
mightnowbedoable.Butthereareanumberofreasonswhyoptimizing
softwarewillalwaysbeneeded.

Afaultydesignorimplementationdecisioninanalgorithmcaneasilyslow
itdown10–100times—whensortingorstoringdata,forexample.Waiting
forhardwarethatisonlytwiceasfastisnotasolution.
Programs,andthedatatheyhandle,tendtogrowlargerandlarger
duringthosesame18months,anduserstendtorunmoreandmore
applicationssimultaneously.Thismeansthespeedrequirementsforthe
programmightincreaseasfastas,andsometimesevenfasterthan,the
hardwarespeedincreases.
Whenprogrammersdonotacquiretheskillstooptimizeprograms,they
willfindthemselvesneedingtoupgradetonewhardwareoverandover
again.
Withsoftwarethatispartofamass-marketsystem(forexample,
embeddedsoftwareinTVs,VCRs,set-topboxes,andsoon),everycent
ofcostwillweighheavily.Investmentsinsoftwareoccuronlyonce,
whereasinvestmentsinhardwareareincurredwitheveryunitproduced.


Whileprocessorscontinuetobecomefasterandcheaper,theirdesigns
changealso.Thismeansthatmoreinvestmentsneedtobemadeto
upgradeotherpartsofthesystems.
Thelowerthesystemrequirementsforacertainprogramare,thelarger
themarketitcanreach.
Buyingnewhardwaretosolvesoftwareproblemsisjustatemporary
workaroundthathidesratherthansolvesproblems.
Onethingtokeepinmindwhentalkingaboutperformanceproblemsis
thattheyaregenerallynotsomuchthetrademarksofentireprogramsas
theyareproblemswithspecificpartsofaprogram.Thefollowingsections
ofthischapterfocusonthoseprogrammingareasthatareparticularly
pronetocausingperformanceproblems.

PerformanceofPhysicalDevices
Whenaprogramusesoneormorephysicaldevices,performanceissues
canariseinthosepartsoftheprogramwhereinteractionwiththese
devicestakesplace.Physicaldevicesareslowerthannormalmemory
becausetheyoftencontainmovingpartsandneedspecialprotocolsfor
access.Also,differentkindsofdevicesoperateatdifferentspeeds.
Importantperformancedecisionsincludedeterminingwhichkindof
devicetouseforwhatpurposeandwhenandwhereintheprogramto
accessthedevices.Chapter12,"OptimizingIO,"explainsthisingreater
detail.
Examplesof(relatively)slowphysicaldevicesincludeharddisks,
smartcardreaders,printers,scanners,diskstations,CD-ROMplayers,
DVDplayers,andmodems.
Herearesomeconsiderationswhenusingphysicaldevices:
1. Itstandstoreasonthatthemorefrequentlyasetofdatais
used,thecloseryouwillwanttoplaceittotheprogram.Data
thatisreferredtoconstantlyshouldtherefore,ifpossible,be
keptininternalmemory.Whenthedatasetisnottoolargeand


remainsconstant,itcouldevenbepartoftheexecutablefile
itself.Whenthedatasetissubjecttochange,however,or
shouldbesharedbetweenprograms,itwouldbewisertostore
itonalocalharddiskandloaditintomemoryatruntime.It
wouldbeunwisetostoreitonanetworkdrive;unlessyou
specificallyintendforthedatatobeaccessedbydifferentwork
stationsortobebackedupremotely,theuseofanetworkdrive
wouldjustaddunwantedoverhead.Thechoiceofdevice
shouldclearlybecloselyrelatedtotheintendeduseofthedata
thatitwillstore.

Duringthedesignphaseofaprogram,lookcloselyathowandwhen
thedataisaccessed.Bymakingatemporarycopyof(ablockof)data,it
ispossibletoincreasethespeedofaccessingit.Forexample,consider
thefollowingscenarioinwhichitisnecessaryforaprogramtoaccess
databeingusedbyaphysicaldevice.Thiscreatesnoproblemwhenboth
theprogramandthedevicearemerelyreadingthedataandnot
changingit.However,whenthedataisbeingchanged,somekindof
lockingmechanismmustbeused.Ofcourse,thistakestime,asthe
programanddevicehavetowaitforeachother.Thistypeofproblemcan
beidentifiedatdesigntime,andpossiblyavoided.Forexample,witha
temporarycopyofthedatasolelyforusebythedevice,theprogram
couldcontinuetomakechangestothedata,whereasthephysicaldevice
isusedmerelyforoutputpurposes(taking,ifyouwill,asnapshotofthe
data).Thiswaytheprogramandthedevicewillnottripovereachother.
Whenthedevicehasfinished,thememorycontainingthecopyofthe
datacanbereused.Iftheamountofdatainvolvedistoolargeeitherto
allowefficientcopyingortobeallocatedinmemorytwice,thesuggested
techniquecouldstillbeapplied,buttosmallersubsetsofthedata.
Itisusuallyagoodideatocompressdatabeforesendingitwhen
communicatingwithrelativelyfastdevicesoveraslowerconnection(two
computersconnectedviaserialcableormodem,forexample).When
choosingthecompressionalgorithm,besurethatthetimethatiswonby
sendinglessinformationovertheconnectionismorethanthetimethatis
neededbytheslowestendoftheconnectiontoperformthecompression
ordecompression.


PerformanceofSystemResources
Notonlyphysicaldevicesbutalsothesystemresourcesthemselvescan
causenoticeableslowdown(EPROM,ROM,RAM,andsoon).Thisdoes

notnecessarilyindicateanincorrectchoiceofhardwarebutitdoesmean
thatcareneedstobetakenfirstduringthedesignphaseandlaterduring
theimplementationphaseofaproject.Forexample,considermoving
partsofROMtoRAMwhenusingROMslowsdowntheprogram.
AlthoughthistypeofcopyactioneatsupthenecessaryCPUclock
cycles,itwillbedoneonlyonceandeverysingleaccesstothememory
inquestionwillbenefitfromafasterresponse.Clearly,onlytheintensely
usedpartsoftheROMshouldbeconsideredforthiskindoftreatment—
andonlywhenthereisenoughmemorytospare.Havingsaidthat,there
neednotbeafragmentationimpactonwhatevermemorymanagement
schemewaschosen,asthispieceofmemorywillmostlikelybeused
duringtheentirelifetimeoftheprogram.RefertoChapter9,"Efficient
MemoryManagement,"formoredetail.
AsimilarenhancementcanbemadeforRAMaccessversusCPU
registers,althoughitsapplicationissomewhatmorelimited.Most
compilersallowyoutomakesuggestionsaboutplacingvariablesdirectly
intotheregistersoftheCPU.Theadvantageofthisisthatregister
accessisevenfasterthanRAMaccess.ForRAMaccess,theCPUhas
tosendarequestfordataontheinternalbustothememoryaddress
mappers,whichinturnhavetointerprettherequesttofindthe
appropriatememoryaddressandsendthecontainedvalueasa
response(someoperatingsystemsalsouseindirectionschemesin
memoryaccess).RegistersarepartoftheCPUchipitselfandcan
thereforebeaccesseddirectly.
Thereisadownsideofcourse.CPUregisterscanhavedifferentsizes
butwillrarelyexceed64bits.Also,thenumberofregistersperCPUis
limitedandafairsharewillbeoccupiedalmostcontinuously.Thatiswhy
inpracticeregisterswillbeusedforvariablesthatareaccessedoften
overshortperiodoftime(loopcountersandsoon).RefertoChapter6,
"TheStandardC/C++Variables,"formoredetailedinformationon

variableuse.


Anotheraspecttotakeintoaccountistheoperatingsystem(OS)
becauseaccessingsystemresourcesisoftendonethroughoperating
systemcalls.Keepinmindthatoperatingsystemsimplementthesecalls
asgenericallyaspossibletobeabletoruneverykindofprogramwith
reasonableresults.Asoftwaredesigner,however,hasmoreinformation
onthetypicalresourceusageofhisprogram.Thisknowledgecanbe
usedtowritemoreefficientinteraction.Forexample,whentheOSusesa
relativelyslowmemorymanagementscheme,certaindesign
considerationscanbemadetocompensate.Aprogrammightbenefit
fromadesigninwhichallocatedmemoryisreusedinternallyinsteadof
releasedbacktothesystem.Chapter9dealsspecificallywiththese
kindsofissues.
Finally,considerexaminingthearchitecturedocumentationoftheCPU(s)
beingused.Thefollowingpracticalexampleshowswhatkindof
optimizationscanbefound.TousetheIntelMMXinstructions,the
coprocessorneedstobesettoMMXmode.Thisswitchcoststime.Then,
whennormalcalculationsneedtocontinue,thecoprocessorneedstobe
switchedbackagain,causingmorelosttime.Sotoavoidunnecessary
switches,instructionsneedtobegroupedbymodeasmuchaspossible
inadesignthatusesthesetwomodes.RefertoChapter4,"Toolsand
Languages,"forinformationontoolstousetodeterminewhichpartsofa
programcauseslowdown.

PerformanceofSubsystems
Anoldproverbsaysachainisonlyasstrongasitsweakestlink.This
holdstruealsoforsoftware,particularlywhenitcomestoperformance
issues.Performanceproblemsarelikelytooccurfromusingabadly

designedthird-partylibrary,orindeedonethatwasoptimizedfora
differentkindofuse.Sobeforeusingsubsystems,itisadvisabletorun
someperformancetests—ifonlytofindoutwhattoexpectinpractice.It
mightbepossibletodesignaroundidentifiedproblems.Butbeprepared
torewriteasubsystemorlookforreplacements.Generallythiswouldbe
consideredthepreferredoption.Otherwisefutureenhancementstothe
programwillcontinuetosufferfromaninitialbadchoice.Avoidcreating
workaroundsifthereiseventheremotestpossibilityofhavingtoreplace
asubsystematsomepointdownthelineanyway.Timeconstraintscould