This message was deleted.
# community-support
s
This message was deleted.
e
presumably that means it took 2 seconds for Gradle to start, determine what to build (nothing, in the case of a no-op build), and do it (or not)
min = 0th percentile = greater than 0% of samples P25 = 25th percentile = greater than 25% of samples median = 50th percentile = greater than 50% of samples P75 = 75th percentile = greater than 75% of samples max = 100th percentile = greater than 100% of samples
in any case, I don't think any single one of these measurements is what you should look at. it's the combination. e.g. if mean is much larger than median, you have some very long-running outliers. if P75 is much higher than median, that's affecting more than 25% of your builds. etc.
👍 1
c
Thanks for teaching! Any ideas why apparently having jetifier enabled is making my builds marginally faster?
every case shows jetifier enabled as being faster... weird. in this project. jetifier isn't actually doing anything. so i guess its possible that it realizes theres nothing to jetifiy and it no ops. so the results are essentially the same. but i was expecting jetifier to be slower
d
When you say nothing to jettify, have you verified that it isn't needed for other dependencies to work?
c
yep. I have a project without jetifier. and for the heck of it (trying to learn more about jetifier and gradle profiler) im purposefully adding jetifier back in.
now i went to a project that still needs jetifier. ran gradle profiler. then switched to a branch we have that removes jetifier (updates one dep) and the one with jetifier still ran faster. weird.
whats the chances gradle profiler is doing something wrong
maybe assembleDebug is the wrong thing to run?