Up to Main Index                           Up to Journal for October, 2012

                   JOURNAL FOR MONDAY 8TH OCTOBER, 2012
______________________________________________________________________________

SUBJECT: When ... is not the same as ./...
   DATE: Mon Oct  8 20:45:11 BST 2012

Recently I've been very busy with 'it pays the bills' type work and had to put
WolfMUD to one side :( Usually I try to juggle my time between WolfMUD and
work but lately things have just gone crazy.

Still I do need to take a break from work now and again. Recently I have been
playing with Go on an emulated ARM platform because it's easy to dip in and
out of and because it's so slow I can leave it doing stuff and come back
later!

What follows may be stating the bloody obvious, but it wasn't obvious to me...

One thing I have noticed is that simply compiling and running WolfMUD on ARM
was taking ages - over 60 seconds. Hrm ... I was using tweaked scripts from my
64bit Linux setup. So I reviewed the scripts. In them I had...


  go install -v ...


Hrm, dot dot dot? I checked out the Go documentation to find out *EXACTLY*
what '...' was doing:


  "An import path is a pattern if it includes one or more "..." wildcards,
  each of which can match any string, including the empty string and strings
  containing slashes. Such a pattern expands to all package directories found
  in the GOPATH trees with names matching the patterns. As a special case,
  x/... matches x as well as x's subdirectories. For example, net/... expands
  to net and packages in its subdirectories."


Seemed innocuous enough.

Then I tried setting up cross compiling[1] to speed things up. Suddenly I was
getting a lot of access denied errors, mainly in the runtime packages. Hrm.
Time to start digging. Why was it trying to recompile runtime stuff?

What it appears to be is that '...' by itself will check all the paths in
GOPATH and also GOROOT - and checks the core packages for out of date objects.
So I changed my scripts to this:


  go install -v ./...


Which I ran with the proper GOPATH specified - otherwise it *seems* [2] to
substitute GOROOT for GOPATH and check core anyway!

Rebuild times dropped from over 60 seconds to 15 seconds. That is with
everything up to date so nothing actually needed rebuilding. Rebuilding all of
WolfMUD dropped from 1 minute 37 seconds to 47 seconds. Not fast but faster ;)

On my normal desktop I didn't even notice the difference: 0.43 seconds down to
0.11 seconds - with everything up to date already. Full WolfMUD build on the
desktop only went from 1.37 seconds to 1.23 seconds which was why I didn't
notice anything before :)

Maybe this will help people with slower systems, maybe it won't.


--
Diddymus

  [1] I haven't got the cross compiling working properly yet. It seems that
      compiling multiple tool chains the way I am skews the timestamps of
      certain common files so they always need rebuilding :( *sigh*

  [2] I've not checked this for certain and I may be wrong!


  Up to Main Index                           Up to Journal for October, 2012