Let Go, Standard Library From Community

[Dan]

Stephen Waits Wrote:
> * Memory access is slow.  Both reading and writing.  It's generally been 
> that way for a long time, and appears to be staying that way.
> 
> * Optimize what is slowest.

Optimize what consumes the most time when the user needs it most.  Having a slow idle process that consumes the cpu time doesn't imply you need to make the idle process more effiicient.  : )

> * Know what's slowest by profiling.

This involves more than invoking a program.  It involves some heuristics.

> * The largest gains generally come from larger algorithmic changes.

I find trivial things like aligning heavily used structs and using in/out/inout parameters in the right places make a big difference and don't even require significant thought.

~~~

To answer his question;

A reference is typically a void**, which essentially means a pair of 32-bit (on a 32 bit system) values stored somewhere.  Those values are used as indexes into the massive array that is your program's memory space (a.k.a: pointers).  If both pointers are already loaded into cache by virtue of being on the same memory page as previously executed data, then dereferencing can take as few as 4 cycles.  In the event of a cache miss, it can take several hundred.  Typically they're kept on the stack, so you almost always get towards the low end.

Passing by value tends to involve moving the data itself, either through registers or the stack (at 1 mov instruction each 32-bit dword).  If the data is less than 128-bits, it tends to be cheaper to pass by value than by reference; and with SSE2, that can be true with data up to 512-bits.

Additionally, once the data has been passed by value, you can manipulate it on the spot; using inout parameters for direct manipulation and in parameters when you only want to touch a copy of the data (copies are as cheap as the original, unlike when passed by reference)

I may have missed some things.  Regardless, those are my thoughts on it atm.

Sincerely,
Dan