Faster compiles? How?!?

Posted by Samson on Fri 25 Nov 2005 04:20 PM — 13 posts, 33,925 views.

Samson USA Fri 25 Nov 2005 04:20 PM #0

Tired of those slow compiles? Thanks to Kiasyn, I was made aware of a new tool that should help with this problem immensely. It's called ccache. What it does basically is caches the results of compiling source code so that the next time it's called on it gets processed alot faster. Compile times are reduced dramatically. More details available here: http://www.debian-administration.org/articles/129

Obviously in order for this to be effective, your server must have the ccache package installed ( mine do ).

Best illustrated with an example. This is done on the AFKMud 2.0 C++ code which is still being worked on, but I think it clearly demonstrates the power of this tool:

Test run on single CPU system running Fedora Core 4 with 768MB RAM
Before
time make clean

[Compiler spam removed]

real 2m51.428s
user 2m36.798s
sys 0m10.317s

After
time make clean

[Compiler spam removed]

real 0m11.418s
user 0m8.641s
sys 0m2.260s

How to use it
So how do you use this? It's very simple. Somewhere in your Makefile there should be a line like this:


CC      = g++

It may specify gcc instead if you're compiling C. To use the cache, simply change it to this:


CC      = ccache g++

The first time you run a clean make, it populates the cache so the compile time will be about normal. But after that is when you can expect to see huge speed boosts from it.

Nick Gammon Australia Forum Administrator Fri 25 Nov 2005 07:49 PM #1

Sounds interesting, but the article says:

Quote:

ccache is a cache for your compiler, every time you compile a source file it saves away the result. Then if you attempt to recompile it again you get the previous result instead of having to invoke the compiler.

Isn't that what "make" does? Only recompiles files that have changed? If you have a proper makefile I don't quite understand where the speed benefit comes from.

Mind you, what is interesting, and should speed up compiles a fair bit is precompiled headers. See:

http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html

I think you need a modern version of gcc (more modern than I have installed). The version it came out in was 3.4.

This gives you a speed improvement because header files (like stdio.h) which rarely change, can be cached, and not re-parsed for every compile.

Samson USA Fri 25 Nov 2005 09:41 PM #2

I realize what they say may not make sense, but it does work. When I can drop a clean make from 2:50 to 11 seconds, I tend to figure whatever magic they do is fine by me.

The only drawback is that the files it keeps ( in ~/.ccache ) will count against any disk space quota the user has, and in my case my test has 39MB of files cached away there.

No C files altered, using makedepend locally
[samson@boralis: ~/Alsherok/src] touch mud.h
[samson@boralis: ~/Alsherok/src] time make
Building AFKMud....
make -s afkmud

[Compiler spam]

Done building AFKMud.
Buidling DNS Resolver...
make -s resolver

real 0m11.219s
user 0m8.389s
sys 0m2.392s

Deliberate non-useful modifications made to act_wiz.c, and imc.c
[samson@boralis: ~/Alsherok/src] touch mud.h
[samson@boralis: ~/Alsherok/src] time make
Building AFKMud....
make -s afkmud

[Compiler spam]

Done building AFKMud.
Buidling DNS Resolver...
make -s resolver

real 0m26.020s
user 0m22.365s
sys 0m2.848s

Conclusion
Seems to have made an obvious difference to me. I chose act_wiz.c and imc.c since they are two files I know take longer to compile than others.

Nick Gammon Australia Forum Administrator Fri 25 Nov 2005 11:30 PM #3

OK, I see what is happening. As the documentation for ccache states, it keeps a hash of the source, and if the hash hasn't changed, uses the cached object. In particular, as they say, if you do:

make clean; make

... it will be faster.

However in a normal build environment you shouldn't have to do that. "make clean" discards all the object files forcing everything to be recompiled, which naturally takes longer. Your "touch mud.h" has the same effect.

Take a look at this thread:



http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=6069

That discusses how you can build in dependency checking, so it should be unnecessary to do "make clean" except in unusual circumstances.

In your current SMAUG FUSS makefile you have this line:



.c.o: mud.h

You probably should at least change it to:



.c.o: $(H_FILES)

That way, if you change another include file than mud.h (eg. imc.h) then the source will be rebuilt.

However a better method would be to use the dependency stuff mentioned above, that way each individual .c file has its own dependencies generated.

For example:



$ gcc -MM mccp.c

mccp.o: mccp.c mud.h color.h hotboot.h mccp.h

This shows the exact .h files that mccp.c is dependent on. Once that is done, then you should never need to do "make clean" and the speedup of caches will be irrelevant.

Nick Gammon Australia Forum Administrator Sat 26 Nov 2005 12:10 AM #4

I've been playing around with the SMAUG FUSS Makefile to try to get the dependency stuff working, bearing in mind that you have the .o files in a subdirectory. This seems to work:


# pull in dependency info for *existing* .o files
-include dependencies.d

ifdef CYGWIN
smaug: $(O_FILES)
        rm -f smaug.exe
        $(CC) -o smaug.exe $(O_FILES) $(L_FLAGS)
        echo "Generating dependency file ...";
        $(CC) -MM $(C_FLAGS) $(C_FILES) > dependencies.d
        perl -pi -e 's.^([a-z]).o/$$1.g' dependencies.d
        echo "Done compiling mud.";
        chmod g+w smaug.exe
        chmod a+x smaug.exe
        chmod g+w $(O_FILES)

clean:
        rm -f o/*.o smaug.exe *~
else
smaug: $(O_FILES)
        rm -f smaug
        $(CC) -o smaug $(O_FILES) $(L_FLAGS)
        echo "Generating dependency file ...";
        $(CC) -MM $(C_FLAGS) $(C_FILES) > dependencies.d
        perl -pi -e 's.^([a-z]).o/$$1.g' dependencies.d
        echo "Done compiling mud.";
        chmod g+w smaug
        chmod a+x smaug
        chmod g+w $(O_FILES)

clean:
        rm -f o/*.o smaug *~
        echo "Generating dependency file ...";
        $(CC) -MM $(C_FLAGS) $(C_FILES) > dependencies.d
        perl -pi -e 's.^([a-z]).o/$$1.g' dependencies.d
endif

New stuff in bold. Basically it uses the C_FILES list to generate a single dependencies file, and then uses perl to put the o/ suffix onto each line. At present the dependencies.d file looks like this:


o/imc.o: imc.c md5.h mud.h color.h hotboot.h imc.h imccfg.h
o/act_comm.o: act_comm.c mud.h color.h hotboot.h imc.h imccfg.h
o/act_info.o: act_info.c mud.h color.h hotboot.h imc.h imccfg.h
o/act_move.o: act_move.c mud.h color.h hotboot.h imc.h imccfg.h
o/act_obj.o: act_obj.c mud.h color.h hotboot.h imc.h imccfg.h bet.h
o/act_wiz.o: act_wiz.c mud.h color.h hotboot.h imc.h imccfg.h
o/ban.o: ban.c mud.h color.h hotboot.h imc.h imccfg.h
o/boards.o: boards.c mud.h color.h hotboot.h imc.h imccfg.h
o/build.o: build.c mud.h color.h hotboot.h imc.h imccfg.h
o/clans.o: clans.c mud.h color.h hotboot.h imc.h imccfg.h
o/color.o: color.c mud.h color.h hotboot.h imc.h imccfg.h
o/comm.o: comm.c mud.h color.h hotboot.h imc.h imccfg.h md5.h mccp.h
o/comments.o: comments.c mud.h color.h hotboot.h imc.h imccfg.h
o/const.o: const.c mud.h color.h hotboot.h imc.h imccfg.h
o/db.o: db.c mud.h color.h hotboot.h imc.h imccfg.h
o/deity.o: deity.c mud.h color.h hotboot.h imc.h imccfg.h
o/fight.o: fight.c mud.h color.h hotboot.h imc.h imccfg.h
o/handler.o: handler.c mud.h color.h hotboot.h imc.h imccfg.h
o/hashstr.o: hashstr.c
o/hotboot.o: hotboot.c mud.h color.h hotboot.h imc.h imccfg.h mccp.h
o/imm_host.o: imm_host.c mud.h color.h hotboot.h imc.h imccfg.h
o/interp.o: interp.c mud.h color.h hotboot.h imc.h imccfg.h
o/magic.o: magic.c mud.h color.h hotboot.h imc.h imccfg.h
o/makeobjs.o: makeobjs.c mud.h color.h hotboot.h imc.h imccfg.h
o/mapout.o: mapout.c mud.h color.h hotboot.h imc.h imccfg.h
o/mccp.o: mccp.c mud.h color.h hotboot.h imc.h imccfg.h mccp.h
o/md5.o: md5.c md5.h
o/misc.o: misc.c mud.h color.h hotboot.h imc.h imccfg.h
o/mpxset.o: mpxset.c mud.h color.h hotboot.h imc.h imccfg.h
o/mud_comm.o: mud_comm.c mud.h color.h hotboot.h imc.h imccfg.h
o/mud_prog.o: mud_prog.c mud.h color.h hotboot.h imc.h imccfg.h
o/planes.o: planes.c mud.h color.h hotboot.h imc.h imccfg.h
o/player.o: player.c mud.h color.h hotboot.h imc.h imccfg.h
o/polymorph.o: polymorph.c mud.h color.h hotboot.h imc.h imccfg.h
o/reset.o: reset.c mud.h color.h hotboot.h imc.h imccfg.h
o/save.o: save.c mud.h color.h hotboot.h imc.h imccfg.h
o/services.o: services.c
o/shops.o: shops.c mud.h color.h hotboot.h imc.h imccfg.h
o/skills.o: skills.c mud.h color.h hotboot.h imc.h imccfg.h
o/special.o: special.c mud.h color.h hotboot.h imc.h imccfg.h
o/tables.o: tables.c mud.h color.h hotboot.h imc.h imccfg.h
o/track.o: track.c mud.h color.h hotboot.h imc.h imccfg.h
o/update.o: update.c mud.h color.h hotboot.h imc.h imccfg.h

Now if you change a file that is only used in a couple of .c files, only they are recompiled:


$ touch md5.h
$ time make
make -s smaug
  Compiling o/imc.o....
  Compiling o/comm.o....
  Compiling o/md5.o....
Generating dependency file ...
Done compiling mud.

real    0m7.369s
user    0m6.910s
sys     0m0.390s

Nick Gammon Australia Forum Administrator Sat 26 Nov 2005 12:14 AM #5

The advantage of this system is that the only overhead is a single 2500 byte file, not the 39 Mb of cache you now have.

Samson USA Sat 26 Nov 2005 02:38 AM #6

[samson@boralis: ~/Alsherok/src] touch md5.h
[samson@boralis: ~/Alsherok/src] time make
Building AFKMud....
make -s afkmud
Compiling o/imc.o....
Compiling o/descriptor.o....
Compiling o/md5.o....
Done building AFKMud.
Buidling DNS Resolver...
make -s resolver

real 0m2.204s
user 0m1.764s
sys 0m0.368s

Combine a makedepend with the cache - your results get even better. I'm not trying to argue one method being superior to the other. Kiasyn just mentioned the compiler cache was not very well publicized, so I decided to do something about that for people who might not otherwise have known about it.

I only have 39MB of cache files because my C++ base is unusually large, probably overuses the STL, and is no doubt bloated beyond belief.

I am certainly still interested in the method you have here for dependency generation if you don't mind my using it for FUSS and/or AFKMud.

Nick Gammon Australia Forum Administrator Sat 26 Nov 2005 02:49 AM #7

Sure, the ccache is an interesting idea, and in certain situations, like where you need to do "make clean" may well improve things.

My timings on compiling SMAUG FUSS (make clean) are:


real    0m51.796s
user    0m49.060s
sys     0m2.090s

You can do that on yours (after clearing the cache) to see our comparative CPU speeds. I suspect your faster time is because you have a faster PC.

Quote:

Buidling DNS Resolver...

That should be "Building".

Quote:

I am certainly still interested in the method you have here for dependency generation if you don't mind my using it for FUSS and/or AFKMud.

Sure, please do. That is why I gave detailed descriptions about how to use it.

Samson USA Sat 26 Nov 2005 05:56 AM #8

Clean make, generated dependencies - no caching:

real 0m18.657s
user 0m16.337s
sys 0m1.748s

Clean make. New dependency file generated. New cache built ( Used "ccache -C" command before running ):

real 0m18.451s
user 0m16.345s
sys 0m1.708s

Touched mud.h with dependency file in place, cache in place:

real 0m3.674s
user 0m2.932s
sys 0m0.660s

Cleared cache, but left dependency file in place. Made actual change to mud.h:

real 0m18.301s
user 0m16.161s
sys 0m1.696s

Made an actual change to mud.h, with dependency file and cache built:

real 0m17.128s
user 0m15.089s
sys 0m1.640s

Reversed the change:

real 0m3.700s
user 0m2.812s
sys 0m0.792s

Basically concluding that it seems to be worth it as long as you're willing to sacrifice the needed disk space. These are the cache stats after all of this was done to the copy of SmaugFUSS 1.6:

[samson@boralis: ~/SmaugFUSS/src] ccache -s
cache directory /home/samson/.ccache
cache hit 755
cache miss 368
called for link 23
not a C/C++ file 2
unsupported compiler option 11
no input file 1
files in cache 80
cache size 3.8 Mbytes
max cache size 976.6 Mbytes

That cache size is about the size of the compiled object files sitting in the src/o directory.

Samson USA Sat 03 Dec 2005 10:57 PM #9

The dependency information works good for SmaugFUSS - I'm having problems with AFKMud though, no doubt due to the number of files. This is the dependency file it generates:

o/imc.o: imc.c mud.h mudcfg.h color.h olc.h imc.h imccfg.h md5.h web.h
o/websvr.o: websvr.c mud.h mudcfg.h color.h olc.h help.h imc.h imccfg.h \
o/ web.h
o/act_comm.o: act_comm.c mud.h mudcfg.h color.h olc.h boards.h language.h
o/act_info.o: act_info.c mud.h mudcfg.h color.h olc.h clans.h fight.h \
o/ liquids.h mxp.h overland.h pfiles.h polymorph.h
o/act_move.o: act_move.c mud.h mudcfg.h color.h olc.h overland.h
o/act_obj.o: act_obj.c mud.h mudcfg.h color.h olc.h clans.h deity.h
o/act_wiz.o: act_wiz.c mud.h mudcfg.h color.h olc.h calendar.h clans.h \
o/ deity.h event.h finger.h imc.h imccfg.h liquids.h msp.h mud_prog.h \
o/ mxp.h overland.h pfiles.h shops.h
o/archery.o: archery.c mud.h mudcfg.h color.h olc.h
o/areaconvert.o: areaconvert.c mud.h mudcfg.h color.h olc.h help.h shops.h
o/auction.o: auction.c mud.h mudcfg.h color.h olc.h auction.h bet.h clans.h \
o/ event.h
o/ban.o: ban.c mud.h mudcfg.h color.h olc.h ban.h
o/bits.o: bits.c mud.h mudcfg.h color.h olc.h bits.h
o/boards.o: boards.c mud.h mudcfg.h color.h olc.h boards.h clans.h deity.h
o/build.o: build.c mud.h mudcfg.h color.h olc.h calendar.h clans.h deity.h \
o/ mud_prog.h overland.h shops.h treasure.h
o/calendar.o: calendar.c mud.h mudcfg.h color.h olc.h calendar.h pfiles.h
o/channels.o: channels.c mud.h mudcfg.h color.h olc.h channels.h
o/clans.o: clans.c mud.h mudcfg.h color.h olc.h auction.h clans.h shops.h
o/color.o: color.c mud.h mudcfg.h color.h olc.h
o/comm.o: comm.c mud.h mudcfg.h color.h olc.h alias.h auction.h ban.h \
o/ calendar.h channels.h connhist.h dns.h fight.h imc.h imccfg.h mccp.h \
o/ md5.h msp.h mxp.h new_auth.h pfiles.h polymorph.h
o/comments.o: comments.c mud.h mudcfg.h color.h olc.h boards.h
o/connhist.o: connhist.c mud.h mudcfg.h color.h olc.h connhist.h
o/const.o: const.c mud.h mudcfg.h color.h olc.h
o/db.o: db.c mud.h mudcfg.h color.h olc.h auction.h bits.h connhist.h \
o/ event.h help.h mud_prog.h overland.h shops.h
o/deity.o: deity.c mud.h mudcfg.h color.h olc.h deity.h
o/editor.o: editor.c mud.h mudcfg.h color.h olc.h editor.h
o/environment.o: environment.c mud.h mudcfg.h color.h olc.h overland.h \
o/ environment.h
o/event.o: event.c mud.h mudcfg.h color.h olc.h event.h
o/event_handler.o: event_handler.c mud.h mudcfg.h color.h olc.h auction.h \
o/ event.h
o/features.o: features.c mud.h mudcfg.h color.h olc.h mccp.h msp.h mxp.h
o/fight.o: fight.c mud.h mudcfg.h color.h olc.h clans.h deity.h fight.h \
o/ event.h
o/finger.o: finger.c mud.h mudcfg.h color.h olc.h calendar.h finger.h
o/handler.o: handler.c mud.h mudcfg.h color.h olc.h deity.h fight.h \
o/ mud_prog.h polymorph.h
o/hashstr.o: hashstr.c
o/help.o: help.c mud.h mudcfg.h color.h olc.h help.h
o/hotboot.o: hotboot.c mud.h mudcfg.h color.h olc.h hotboot.h mccp.h imc.h \
o/ imccfg.h
o/iafk.o: iafk.c mud.h mudcfg.h color.h olc.h calendar.h clans.h deity.h \
o/ msp.h mxp.h
o/idale.o: idale.c mud.h mudcfg.h color.h olc.h calendar.h clans.h deity.h \
o/ msp.h mxp.h
o/imm_host.o: imm_host.c mud.h mudcfg.h color.h olc.h imm_host.h
o/interface.o: interface.c mud.h mudcfg.h color.h olc.h clans.h mxp.h
o/interp.o: interp.c mud.h mudcfg.h color.h olc.h alias.h clans.h
o/ismaug.o: ismaug.c mud.h mudcfg.h color.h olc.h calendar.h clans.h \
o/ deity.h msp.h mxp.h
o/liquids.o: liquids.c mud.h mudcfg.h color.h olc.h liquids.h
o/magic.o: magic.c mud.h mudcfg.h color.h olc.h clans.h fight.h liquids.h \
o/ overland.h polymorph.h
o/md5.o: md5.c md5.h
o/misc.o: misc.c mud.h mudcfg.h color.h olc.h liquids.h
o/mspecial.o: mspecial.c mud.h mudcfg.h color.h olc.h fight.h mspecial.h
o/mudcfg.o: mudcfg.c mud.h mudcfg.h color.h olc.h clans.h deity.h
o/mud_comm.o: mud_comm.c mud.h mudcfg.h color.h olc.h bits.h deity.h \
o/ mud_prog.h overland.h polymorph.h
o/mud_prog.o: mud_prog.c mud.h mudcfg.h color.h olc.h bits.h clans.h \
o/ deity.h mud_prog.h polymorph.h
o/new_auth.o: new_auth.c mud.h mudcfg.h color.h olc.h new_auth.h
o/olcmob.o: olcmob.c mud.h mudcfg.h color.h olc.h mspecial.h
o/olcobj.o: olcobj.c mud.h mudcfg.h color.h olc.h liquids.h treasure.h
o/olcroom.o: olcroom.c mud.h mudcfg.h color.h olc.h overland.h
o/overland.o: overland.c mud.h mudcfg.h color.h olc.h overland.h ships.h \
o/ skyship.h
o/pfiles.o: pfiles.c mud.h mudcfg.h color.h olc.h clans.h deity.h pfiles.h
o/player.o: player.c mud.h mudcfg.h color.h olc.h deity.h mxp.h
o/polymorph.o: polymorph.c mud.h mudcfg.h color.h olc.h deity.h polymorph.h
o/rent.o: rent.c mud.h mudcfg.h color.h olc.h auction.h clans.h connhist.h \
o/ hotboot.h new_auth.h overland.h
o/renumber.o: renumber.c mud.h mudcfg.h color.h olc.h mud_prog.h overland.h \
o/ shops.h
o/reset.o: reset.c mud.h mudcfg.h color.h olc.h overland.h
o/save.o: save.c mud.h mudcfg.h color.h olc.h alias.h bits.h boards.h \
o/ channels.h clans.h deity.h finger.h
o/ships.o: ships.c mud.h mudcfg.h color.h olc.h overland.h ships.h
o/shops.o: shops.c mud.h mudcfg.h color.h olc.h clans.h mxp.h shops.h
o/skills.o: skills.c mud.h mudcfg.h color.h olc.h fight.h overland.h \
o/ polymorph.h
o/skyship.o: skyship.c mud.h mudcfg.h color.h olc.h overland.h skyship.h
o/slay.o: slay.c mud.h mudcfg.h color.h olc.h slay.h
o/tables.o: tables.c mud.h mudcfg.h color.h olc.h language.h
o/track.o: track.c mud.h mudcfg.h color.h olc.h fight.h
o/treasure.o: treasure.c mud.h mudcfg.h color.h olc.h clans.h treasure.h
o/update.o: update.c mud.h mudcfg.h color.h olc.h auction.h clans.h deity.h \
o/ imc.h imccfg.h mud_prog.h new_auth.h polymorph.h

Samson USA Sat 03 Dec 2005 10:58 PM #10

With the above dependency files, I keep getting this:


[afkmud@boralis: ~/afkmud/src] make
make -s afkmud
  Compiling o/websvr.o....
  Compiling o/act_info.o....
  Compiling o/act_wiz.o....
  Compiling o/auction.o....
  Compiling o/build.o....
  Compiling o/comm.o....
  Compiling o/db.o....
  Compiling o/environment.o....
  Compiling o/event_handler.o....
  Compiling o/fight.o....
  Compiling o/handler.o....
  Compiling o/hotboot.o....
  Compiling o/iafk.o....
  Compiling o/idale.o....
  Compiling o/ismaug.o....
  Compiling o/magic.o....
  Compiling o/mud_comm.o....
  Compiling o/mud_prog.o....
  Compiling o/overland.o....
  Compiling o/rent.o....
  Compiling o/renumber.o....
  Compiling o/save.o....
  Compiling o/skills.o....
Generating dependency file ...
Done compiling mud.

Each of those files it keeps reprocessing matches with the dependency file where perl broke the line and put a \ at the end and then continued it to the next.

Nick Gammon Australia Forum Administrator Sun 04 Dec 2005 12:35 AM #11

Yes, I noticed that, and a recent post about makefiles I changed it to a slightly different perl line.

I have amended the post further up this page to avoid confusion.

Basically you replace the "perl" line with this:



 perl -pi -e 's.^([a-z]).o/$$1.g' dependencies.d

This only adds the "o/" string to the start of lines that start with a letter, this therefore excludes the continuation lines.

BTW Samson, did you notice my post about an access violation in SMAUG? :

http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=6109

Samson USA Sun 04 Dec 2005 01:52 AM #12

Sweet, the modified perl line fixed it.

And no, I hadn't noticed the other post. Generally gets noticed alot faster when stuff like that is reported on the FUSS forusm :)