I'm pretty sure we name all the threads we can (or at least used to), I
*think* the problem is worker threads in a thread pool, which are started up
and shut down automatically, and aren't named (and don't have message
loops).
When I was doing the work to generate the internal page about:tasks,
One trick that I've regularly done when concerned about the perf impact of
a patch is to:
a) Wait till late at night pacific time, when very few checkins are landing
(often there are multi-hour gaps).
b) Land your change, and wait till the build bots all start building (about
a minute later).
Will we have any chance to ship both, and randomly select (at startup
time??) between the two dictionaries? Alternatively, could we ship a series
of dev builds, and alternate use of old an new dictionaries.
The bottom line IMO is that when running experiments, you need the closest
to
I'm quite sure it is jemalloc. I failed miserably by not over-communicating
this checkin. My apologies to all that I have inconvenience.
We have just this week identified a number of misteps in our use of
TCMalloc. I think that we can eventually reach an excellent result with
TCMalloc... and we
[Repost... this time from my chromium account... so it is posted more
broadly]
-- Forwarded message --
Date: Wed, Sep 30, 2009 at 10:39 AM
Subject: [Memory] in TCMalloc, more careful handling of VirtualAlloc commit
via SystemAlloc
To: Mike Belshe mbel...@google.com, Anton Muhin
+1
On Wed, Sep 23, 2009 at 5:52 AM, progame prog...@chromium.org wrote:
sounds like this issue http://crbug.com/20451
On Sep 22, 8:39 pm, Daniel Cowx daniel.c...@gmail.com wrote:
Can someone please provide a bit of insight into how to solve the
following problem:
1. Open Chromium
In the case you indicated, the main thread call stack probably includes the
invocation of the nested message loop. I think this nesting is usally
required because we enter a special windows message loop that handles native
windows (dialog boxes). We use some very fancy footwork to cause this
+1 for Peter's suggestion.
TimeDelta has an internal accuracy of microseconds. What resolution/scaling
do you want to print in a check? Sometimes it is minutes, sometimes
seconds, sometimes milliseconds, I doubt that we want microseconds :-/.
Explicit conversion as suggested doesn't seem that
dump instead of the erroneous values.
On Thu, Aug 20, 2009 at 6:49 PM, Matt Perry mpcompl...@chromium.orgwrote:
Andrew wants to be able to do:
DCHECK_EQ(expected_time_delta, time_delta);
This can't be done without operator support.
On Thu, Aug 20, 2009 at 6:46 PM, Jim Roskind j
+1 Darin
+1 Maruel
It was/is impressively hard to modify the message loop/pump without harming
performance, and that performance is so central, that it tends to be visible
in top level browser benchmarks.
It was very difficult to make this body of code as simple() as it is.
...and it is not
If that was not enough of a trick question:
Suppose you checkin with 5 other people at the same time, and the tree goes
red as a consequence of that group's landing, but you are sure you didn't
break the tree. Are YOU responsible to help fix it?
Answer: *YES*, you are responsible.
For me, all
I think you're somewhat right folks use tabs to enhance or partially
replace poor history systems. Instead of going to the root to create a
good history system and telling users to stop doing that, perhaps we
should be asking how can we enhance what the user wants to do: *Use tabs (in
their
I tend to think incognito mode as a personal (and very private) decision.
As a result, I'd tend to prefer that it be very difficult to leak such
status further than absolutely necessary. Allowing your proxy provider to
detect this status seems like a violation of the need to know, but perhaps
re: Your comment the cost is big.
FWIW: One item that I recall was very complex was the message loop
implementation, which handles both native Windows events and coordinates
inter-thread Task processing.. It was quite difficult to create a task
processing system that integrated with the Windows
I think the question of when a page is fully loaded is a bit hard to get
perfect... as lots of pages do stuff after they've loaded that won't really
impact the presentation... but there is no way to know that the JS programs
won't make further changes :-/.
That said, Dave Moore put in some code to
+1 Please do not remove it. It is VERY valuable for development and
debugging across renderer and browser.
IMO, it should be maintained at least enough to mostly run (at least past
startup as shown above). If this startup failure can be reproduced, it
should be filed as a bug and fixed. I have
Perhaps we need to think about how to encourage such a restart, without
being the traditional pop-up pain-in-the-er-um-rear.
Can we find real-estate that won't tend to detract from the ui to alert the
user that an update is pending? Perhaps atop a new-tab page? Perhaps an
extra entry ot the
:
It randomly happen on windows try slave every day.
On Tue, Mar 17, 2009 at 2:41 PM, Bradley Nelson bradnel...@google.com
wrote:
Did this ever get resolved?
I'd be eager to hear about any trouble with gyp.
-BradN
On Mon, Mar 16, 2009 at 5:44 PM, Jim Roskind j...@chromium.org wrote:
Just a wild
Just a wild guess... please ignore if this is not applicable:
Any chance you pulled on Friday eve between 5pm and 8pm pacific time? If
so, you might have gotten your tree a little wedged. When you do a gclient
sync, does it skip any of the files because there is a gyp generated file
in the way
If you're not chasing after performance and stats issues in the renderer,
you can stop reading now.
Thanks to the work by Raman Tenneti, the support for histograms that has
been available in the Browser process, is now provided in the Renderer
processes. Histograms gathered in Renderers are
IMO, the big grouping distinction for startup code is a) code that needs to
be performed while single threaded; vs b) code that can run while
multi-threaded.
The first group effectively replaced the Google-style-illegal global static
initializers, and allows slight variation of ordering between
I've turned on the experimental SDCH compression protocol by default for the
.google.com domain only. Currently Google is helping to test support by
serving some web pages using this protocol (to browsers that support it), so
this default change will only impact search at google.com If things go
see various stats about its activity (e.g., dictionary sizes and counts; pre
and post compression sizes (excluding gzip); etc.).
The rest of the email is hopefully more factual.
Jim
On Fri, Oct 24, 2008 at 4:01 PM, Jim Roskind [EMAIL PROTECTED] wrote:
I've turned on the experimental SDCH
On Sun, Oct 19, 2008 at 9:42 PM, Peter Kasting [EMAIL PROTECTED]wrote:
On Sun, Oct 19, 2008 at 9:16 PM, Jim Roskind [EMAIL PROTECTED] wrote:
Note this code is not yet pushed to either Google Chrome's dev channel,
nor beta channel. I've only landed this on the Chromium tip-of-tree thus
far
24 matches
Mail list logo
