Page MenuHomePhabricator

Batch up SQL operations in the `./bin/repository parents` script.
ClosedPublic

Authored by joshuaspence on Jun 3 2014, 5:23 PM.
Tags
None
Referenced Files
F13207313: D9361.diff
Wed, May 15, 10:14 PM
F13196508: D9361.diff
Sun, May 12, 11:20 PM
Unknown Object (File)
Fri, May 3, 3:56 AM
Unknown Object (File)
Mon, Apr 29, 2:59 PM
Unknown Object (File)
Wed, Apr 24, 10:21 PM
Unknown Object (File)
Mon, Apr 22, 4:15 PM
Unknown Object (File)
Apr 7 2024, 2:49 PM
Unknown Object (File)
Apr 6 2024, 12:28 AM
Subscribers

Details

Summary

Fixes T5255. Currently the ./bin/repository parents workflow is quite slow. Batching up the SQL operations should make the workflow seem much faster.

Test Plan

Not yet tested.

Diff Detail

Repository
rP Phabricator
Branch
repo_parents
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 828
Build 828: [Placeholder Plan] Wait for 30 Seconds

Event Timeline

joshuaspence retitled this revision from to Batch up SQL operations in the `./bin/repository parents` script..
joshuaspence updated this object.
joshuaspence edited the test plan for this revision. (Show Details)
joshuaspence added a reviewer: epriestley.

We probably need PhabricatorLiskDAO::chunkSQL() around the actual queries to prevent overflowing the packet limit. This looks reasonable otherwise.

joshuaspence edited edge metadata.
  • Use PhabricatorLiskDAO::chunkSQL

I'm not sure whether this is actually helping my initial issue... the whole process still seems very slow. I am investigating now.

(which means the SELECTs probably need to be batched as well)

In fact, I'm not convinced that this is much faster at all...

Before

> time ./bin/repository parents PP
Rebuilding "rPP"...
Rebuilding branch "production"...
Found 3,714 total commit(s); updating...
Done.                                                                         
                                                                              
real	3m16.982s
user	0m12.769s
sys	2m14.456s

After

time ./bin/repository parents PP
Rebuilding "rPP"...
Rebuilding branch "production"...
Found 3,714 total commit(s); updating...
Done.                                                                         
                                                                              
real	3m1.038s
user	0m11.441s
sys	2m17.209s

With select batching, this drops from 30s to ~2s for me locally when run on the Phabricator repo:

https://secure.phabricator.com/differential/diff/22292/

Batch SELECT statements as well.

This didn't seem to help either.

> time ./bin/repository parents PP        
Rebuilding "rPP"...
Rebuilding branch "production"...
Found 3,714 total commit(s); updating...
Done.                                                                         
                                                                              
real	3m11.955s
user	0m11.469s
sys	2m31.537s

(Is the fully batched version faster for you?)

Hmm, try with --trace?

Interestingly, --trace caused the script to terminate after a few seconds...

With D9363 applied:

time ./bin/repository parents PP
Rebuilding "rPP"...
Rebuilding branch "production"...
Found 3,714 total commit(s); updating...
Done.                                                                         
                                                                              
real	0m1.545s
user	0m0.712s
sys	0m0.624s

:D

This diff may not be required after D9363, with just D9363 applied there is a 6 times speed improvement for me:

> time ./bin/repository parents PP        
Rebuilding "rPP"...
Rebuilding branch "production"...
Found 3,714 total commit(s); updating...
Done.                                                                         
                                                                              
real	0m32.059s
user	0m3.736s
sys	0m9.913s
epriestley edited edge metadata.

I'm going to grab this too since it does provide a real performance increase and the complexity is reasonably well isolated, it just pales in comparison to the progress bar perf issue.

This revision is now accepted and ready to land.Jun 3 2014, 6:27 PM
epriestley updated this revision to Diff 22298.

Closed by commit rP1503840cd945 (authored by @joshuaspence, committed by @epriestley).