On 3 December 2010 11:29, Justin Lebar wrote:
>>> Even on a ccache *hit* both copies of the .o file wind up occupying
>>> buffer cache space, because the ccached .o is read from disk [paging
>>> it in] in order to write the .o file to the build output directory.
>>> On a ccache miss the copy runs
>> Even on a ccache *hit* both copies of the .o file wind up occupying
>> buffer cache space, because the ccached .o is read from disk [paging
>> it in] in order to write the .o file to the build output directory.
>> On a ccache miss the copy runs the other direction but you still wind
>> up with b
On 3 December 2010 03:42, Christopher Tate wrote:
>> I'd love to know whether you also tried distcc for it, and if so what
>> happened or what went wrong. (Obviously it can only help for the
>> C/C++ phases.)
>
> distcc can certainly help a great deal. For us, it's a bit
> problematic to use bec
On Wed, 2010-12-01 at 21:47 -0500, Paul Smith wrote:
> Now I'm on to my next problem. In order to get this to happen I have
> to set CCACHE_BASEDIR to strip off the workspace directory prefix, so
> that the per-workspace filenames are not embedded in the cache. This
> works (see above), however t
On Wed, Dec 1, 2010 at 9:00 PM, Martin Pool wrote:
> On 11 November 2010 10:56, Christopher Tate wrote:
>> I don't want to rain on peoples' parade here, because ccache is a
>> great product that has real benefits, but I do want to share some of
>> our findings regarding the use of ccache in our v
>...
>When ccache invokes my compiler, it runs like this:
>
>cd /path/to/ONE/obj/subdir/foo
>my-special-gcc -c -E ../../../src/subdir/foo/foo.c
>
>This works, as you can see above. But, it's a serious drag from a
>debugging standpoint, because now the pathname for that file in my
On 11 November 2010 10:56, Christopher Tate wrote:
> I don't want to rain on peoples' parade here, because ccache is a
> great product that has real benefits, but I do want to share some of
> our findings regarding the use of ccache in our very large product --
> we were surprised by them, and you
Hi all; I got sidetracked on this for a while but I'm back at it.
So, I think I have the encapsulated compiler working OK now; I am able
to get almost complete sharing of objects between two workspaces; after
a clean build of (just a small part of) the first workspace my cache
has:
cache
On 2010-11-11 00:56, Christopher Tate wrote:
> [...]
> The issue is around VM/file system buffer cache management. If you're
> using ccache, then you'll effectively be doubling the number of .o
> files that are paged into memory during the course of a build.
> [...]
By the way, have you tried set
On 2010-11-11 00:56, Christopher Tate wrote:
I don't want to rain on peoples' parade here, because ccache is a
great product that has real benefits, but I do want to share some of
our findings regarding the use of ccache in our very large product
> [...]
Many thanks for sharing your findings! I
On 2010-11-10 23:54, Paul Smith wrote:
> [...]
So, my question is, is the NAME of the compiler part of the hash as well
as the mtime/size, so that ccache won't consider the second one to be a
copy of the first?
Yes, the compiler name is included in the hash. As you note, this is not
clear from
On Wed, 2010-11-10 at 15:56 -0800, Christopher Tate wrote:
> Very short version: if your 'make' dependencies or equivalent are
> well-written, using ccache will almost always *increase* your
> incremental build times. This wasn't immediately obvious to us but
> makes sense in hindsight: if your d
I don't want to rain on peoples' parade here, because ccache is a
great product that has real benefits, but I do want to share some of
our findings regarding the use of ccache in our very large product --
we were surprised by them, and you may be as well. These findings are
specifically for *large
13 matches
Mail list logo
