On Thu, Aug 20, 2009 at 11:33 AM, Jeremy Orlow wrote:
> Are you positive it's the per-file presubmit checks slowing things down?
> If so, maybe the presubmit stuff needs to be re-factored? Right now, it
> does each presubmit check one by one (and each check might read in the
> files). If it we
On Thu, Aug 20, 2009 at 11:40 AM, Marc-Antoine Ruel wrote:
> The commit checks is bound to 2x appengine latency (hint hint) since
> it parses try job results registered on rietveld and looks up
> chromium-status to know if the tree is open.
>
I wasn't talking about commit check, just upload (alth
The commit checks is bound to 2x appengine latency (hint hint) since
it parses try job results registered on rietveld and looks up
chromium-status to know if the tree is open.
presubmit_support.py still reads the whole file. It's *supposed* to
only load the new lines from the diff. I just assumed
Are you positive it's the per-file presubmit checks slowing things down? If
so, maybe the presubmit stuff needs to be re-factored? Right now, it does
each presubmit check one by one (and each check might read in the files).
If it were changed to go file by file (reading fully into memory, runnin
Great! Please try to add this to an existing check, or do it in a way that
doesn't involve the files being read once for each presubmit check, as the
presubmit step is already too slow.
On Thu, Aug 20, 2009 at 11:16 AM, Paweł Hajdan Jr.
wrote:
> Cool! Thanks so much. I'm going to write a presubm
Cool! Thanks so much. I'm going to write a presubmit check for that.
On Thu, Aug 20, 2009 at 11:12, John Abd-El-Malek wrote:
> Including files like render_messages.h and automation_messages.h from other
> header files is unnecessary and slows down the build (adds about ~100K lines
> of headers t