https://pantsbuild.org/ logo
Join Slack
Powered by
I'm just a little confused to how to start debuggi...
# general
a
I'm just a little confused to how to start debugging this or how to figure out what's going on that's causing the discrepency
@hundreds-father-404 moving the performance stuff here since the other thread got a little derailed
Copy code
(remit) [nate@ragin-cajun remit-srv]$ time pytest tests/test_aml_actions.py
======================================================================================================= test session starts ========================================================================================================
platform linux -- Python 3.8.5, pytest-6.0.1, py-1.9.0, pluggy-0.13.1
rootdir: /home/nate/wave/remit-srv
plugins: celery-4.4.7, requests-mock-1.8.0, Faker-4.1.1, cov-2.10.1
collected 37 items

tests/test_aml_actions.py .....................................                                                                                                                                                              [100%]

======================================================================================================== 37 passed in 1.46s ========================================================================================================

real	0m6.757s
user	0m5.114s
sys	0m1.107s
(remit) [nate@ragin-cajun remit-srv]$ time ./pants test --force tests
11:30:27.95 [INFO] Completed: test - tests/test_aml_actions.py succeeded.

āœ“ tests/test_aml_actions.py succeeded.

real	0m9.105s
user	0m0.437s
sys	0m0.027s
on the new release candidate it still takes about 50% longer to run the tests - is that expected?
more specifically the actual test running takes longer (as reported by pytest) 
pytest -s tests/test_aml_actions.py
-> 
37 passed in 1.46s
./pants test --output=all --force tests/test_aml_actions.py
-> 
37 passed, 86 warnings in 2.13s
I'm not sure how to tell how to determine what how pants is running pytest differently?
h
Cool I see you're using 
--force
. Is this consistent? Are you using pantsd (on by default)? I don't think I'd expect that much overhead, but some known remaining places of Pants overhead 1. ~0.6s to start up Pantsd at first 2. iiuc, the first time you create a new Pex like when it says creating 
pytest_runner.pex
, there is some time involved to unzip it, but then it's cached 3. .pyc files are not cached so must be recompiled every time 4. general Pants overhead of things like determining dependencies Running this command a second time with pantsd enabled should nullify 1 and 4. Regardless of pantsd, running a second time should nullify 2. Leaving the .pyc files as a likely culprit for why this is still slower
(FYI we're planning to address 1 by porting more of Pants to Rust, and 3 is tracked by https://github.com/pantsbuild/pants/issues/11339. No fix for 2, but it's minor and only one time. 4 is why we have the pants daemon to avoid redoing work)
w
are the timings in this thread with 
2.3.x
?
h
Yeah
šŸ‘ 1
w
as to actually debugging this, setting 
--no-process-execution-cleanup-local-dirs
and then seeing how long the 
__run.sh
script in the captured directory (it will be logged) takes to run would be helpful
āž• 1
šŸ’Æ 1
independently (in a different run, probably), setting 
-ldebug
will render more of the log, which will help point to the process runtime vs overhead
h
and 
--no-dynamic-ui
can be helpful to print "starting" messages so you can see the time between "starting" and "completed"
w
they render at debug, iirc
a
hey sorry for the delayed reply I got sucked into the et_xmlfile stuff I am using --force but I ran it 4 times to get a consistent reading (first time ~13 seconds total, afterward consistent at 8.9 seconds) timings are all with 2.3.x
šŸ‘ 1
cool I will check out those suggestions! thanks šŸ™
Open in Slack
PreviousNext
Powered by