Hi, all.
I ran ccache through |perf| on my x64 Linux box today. In my testcase
(|make clean perf record -g make| within a subdirectory of the
Firefox tree), there are only four functions that see more than 2% of
the samples:
25.39% c++ ccache [.]
)
With ccache, preprocessor mode, cache hit:1.66 s ( 25.56 %) ( 3.91 x)
With ccache, direct mode, cache miss: 7.94 s (121.95 %) ( 0.82 x)
With ccache, direct mode, cache hit: 0.28 s ( 4.34 %) (23.04 x)
On Mon, Nov 8, 2010 at 2:06 PM, Justin Lebar justin.le...@gmail.com 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 the other direction but you still wind
up with both sets
Do you need to hash in the cwd when compiling with -fprofile-generate?
If I use direct mode and don't have any absolute paths in my build, it
looks like I could have a cache hit between two compiles in different
directories. That would be bad, since I think the absolute path the
.gcda is output
+ if (output_to_real_object_first) {
+if (copy_file(tmp_obj, cached_obj, enable_compression) != 0) {
+ cc_log(Failed to move %s to %s: %s, tmp_obj, cached_obj,
strerror(errno));
+ stats_update(STATS_ERROR);
+ failed();
+}
Maybe you should hardlink, if CCACHE_HARDLINK is
:
On Mon, Aug 8, 2011 at 4:24 PM, Justin Lebar justin.le...@gmail.com wrote:
The .gcda files themselves aren't cached, their contents are used to
calculate the hash for a -fprofile-use run. So if the .o file doesn't
exist, and you have the same .gcda file, you get a cache hit.
Ah, I see. What
Looking at a ccache with about 40,000 .o files in it (created with direct
mode turned on); of the 55 largest files, I found 11 pairs and one triplet
of identical object files. That's almost 25% of redundant storage that
could have been avoided by looking at the preprocessed hash when there is
Better to do 2 seconds, since FAT (and maybe some other Windows
related setups) has only a 2-second resolution.
The other thing you can do is, on Unix, use the latest of ctime and
mtime, which should catch cases where the mtime gets reset.
Thanks for the tips!
I'm happy to update the patch,
I've encountered a bug while playing with ccache: temporal macros are not
detected correctly.
Ouch!
* the assumption that 'E' is less common in source than '_',
we check
* str[i-2] first.
Update the comment?
while (i len) {
I think this fails on at
Can you update the Python script in the comment right above the code
and confirm that it matches your new table? It's hard for me to see
what you did here based on just the patch...
On Tue, Oct 9, 2012 at 10:43 AM, Andrew Stubbs a...@codesourcery.com wrote:
On 08/10/12 19:25, Justin Lebar wrote
of this, since it's obviously
tricky to get right!
On Tue, Oct 9, 2012 at 11:05 AM, Andrew Stubbs andrew_stu...@mentor.com wrote:
On 09/10/12 15:46, Justin Lebar wrote:
Can you update the Python script in the comment right above the code
and confirm that it matches your new table? It's hard
] Detect __DATE__ and __TIME__ correctly.
To: Justin Lebar justin.le...@gmail.com
Cc: Andrew Stubbs a...@codesourcery.com, ccache@lists.samba.org
ccache@lists.samba.org
On 09/10/12 15:46, Justin Lebar wrote:
Can you update the Python script in the comment right above the code
and confirm
.
I'd also appreciate if some of you could test this patch by turning on
CCACHE_SLOPPINESS=file_stat_matches and letting me know if you have
any problems.
Happy holidays.
-Justin
On Sun, May 20, 2012 at 4:49 PM, Justin Lebar justin.le...@gmail.com wrote:
This patch lets ccache examine an include
2012 08:18, Justin Lebar justin.le...@gmail.com wrote:
Hi, all.
I've resurrected these patches to look at files' mtimes and ctimes.
Hopefully the three patches here (with their commit messages) don't
need further explanation. Note that the second patch here increases
safety for everyone
14 matches
Mail list logo
