#general
- b
bored-art-40741
09/11/2015, 5:00 PMOur next upgrade will almost certainly be to the isolated strategy, unless there's something big we're missing - b
bored-art-40741
09/11/2015, 5:00 PMEven the memory issues at this point could probably be dealt with by tuning heaps and the number of parallel workers in zinc - b
bored-art-40741
09/11/2015, 5:00 PMIt would be suboptimal but not a show stopper - w
witty-crayon-22786
09/11/2015, 5:01 PMwe have a goal of continued performance improvements through the end of the quarter, and the two things that we're tackling to do that are 1) figuring out memory-related stalls that happen periodically in CI (ie, what you're looking at, and 2) the jar work - w
witty-crayon-22786
09/11/2015, 5:01 PMso on one hand, we're already investigating the thing that is blocking you - b
bored-art-40741
09/11/2015, 5:01 PMI think you should also consider the product accumulation that happens just before invoking zinc - b
bored-art-40741
09/11/2015, 5:02 PMThe part where it hunts for classfiles already on the classpath that might be claimed - w
witty-crayon-22786
09/11/2015, 5:02 PMproduct accumulation happens after compilation - w
witty-crayon-22786
09/11/2015, 5:02 PMbut yes - b
bored-art-40741
09/11/2015, 5:02 PMI dropped prints to watch it happen - w
witty-crayon-22786
09/11/2015, 5:02 PMnote that that becomes almost entirely unnecessary with isolated - b
bored-art-40741
09/11/2015, 5:02 PMOne sec - w
witty-crayon-22786
09/11/2015, 5:03 PM@bored-art-40741: any targets which have already been compiled in previous rounds will just immediately have their products registered - w
witty-crayon-22786
09/11/2015, 5:03 PMwhich is likely what you saw - b
bored-art-40741
09/11/2015, 5:03 PMsrc/python/pants/backend/jvm/tasks/jvm_compile/jvm_compile.py:273 - b
bored-art-40741
09/11/2015, 5:03 PMThat is the code I'm talking about - b
bored-art-40741
09/11/2015, 5:03 PMI believe this is only visible in an unclean workspace during incremental compiles - w
witty-crayon-22786
09/11/2015, 5:03 PMyea, exactly. see above. - w
witty-crayon-22786
09/11/2015, 5:04 PM...but actually, products are always registered - w
witty-crayon-22786
09/11/2015, 5:04 PMthey just aren't hidden behind cold compilations during an incremental compile - b
bored-art-40741
09/11/2015, 5:04 PMOkay. It's possible that for isolated this is not an issue - w
witty-crayon-22786
09/11/2015, 5:04 PMso they show up red hot. - b
bored-art-40741
09/11/2015, 5:04 PMIt's a massive issue for global with missing dep check enabled, which flips on one more product - w
witty-crayon-22786
09/11/2015, 5:04 PM"classes_by_target" should go away essentially - b
bored-art-40741
09/11/2015, 5:04 PMIt might be the accumulation of that product which is blocking us from upgrading (while still on global) - w
witty-crayon-22786
09/11/2015, 5:05 PMi'm guessing it's the product that's used for the dependency check - b
bored-art-40741
09/11/2015, 5:05 PMYes - w
witty-crayon-22786
09/11/2015, 5:05 PMwhich is only requested when the dependency check is enabled - b
bored-art-40741
09/11/2015, 5:05 PMproduct_deps_by_src - b
bored-art-40741
09/11/2015, 5:06 PMYeah, but global is unsafe without the dep check enabled. And when I say a perf issue, I actually mean a perf bug