Status Update
No update yet.
Comments
jf...@block.xyz
rp...@google.com
We want benchmarks to measure code after Progaurd / R8, but it's not possible to turn that on for androidTests in library modules at the moment (to my knowledge?)
Benchmarks are also a public facing thing, but we have a plugin to help configure gradle builds for our users, so if support for this ends up in a private API, we could try to keep those usages localized to our code perhaps.
jf...@block.xyz
Any update on the status of this request and when it can be supported?
Thanks,
Amanda
vm...@google.com
jf...@block.xyz
this is not part of our OKR at this point so we are not talking soon. at first glance, we would need to simulate usage patterns to minify against and such, this seems substantial amount of work. there are not a lot of library module that have android tests, most only rely on unit-tests.
how important is this ? we are out of PM right now but I suspect the next step will be to negotiate with J. Eason and xav@ to scale a priority level.
cm...@google.com
This is a high priority request for Compose, to enable their benchmarks to measure release accurate performance. (Micro) Benchmarks are library modules, as they don't need the complexity of multi-apk tests - they're self measuring APKs that depend on libraries. (d.android.com/benchmark)
there are not a lot of library module that have android tests, most only rely on unit-tests.
To clarify, this is for com.android.library modules, not jars - I'd expect most of those to use android tests (all of the libraries in jetpack for example do).
we would need to simulate usage patterns to minify against and such, this seems substantial amount of work
Simulate usage patterns? I don't understand - the dev can themselves provide a keep rule for test infra / classes if necessary. Long term, keep rules should be provided by test libraries.
cm...@google.com
cm...@google.com
We've been experimenting with ways to work around this for Compose. Performance results from R8 seem significantly different, and would enable us to measure much more accurately. I've tried to come up with a workaround using a com.android.app module, and while it almost works (and we can get measurements), it's extremely hacky and doesn't let us run tests anymore via Studio:
an...@google.com
Bumping this request, as Compose has recently had more interest in the ability to benchmark with and without R8 enabled.
We're fine if the default implementation doesn't work with minification (tree shaking) - we're happy to supply those rules ourselves, or simply evaluating with minification off to take advantage of other optimizations.
jf...@block.xyz
Juan, this might be something to put on our OKR in the near future, I think you chat with Amanda to set the priority.
vm...@google.com
Hey everyone, I am catching up on feature requests and saw this one. I'll schedule time for us to talk about this in a few days.
jf...@block.xyz
Ivan, can you provide a rough estimate on how long this would take ?
Description
Originally reported
Original report to intellij copied below:
Steps to reproduce
2024.9JetGradlePluginExpected result (correct result):
No isolated projects issues
Actual result (faulty result):
You will see thousands of the following isolated projects violation:
Project ':whatever' cannot dynamically look up a property in the parent project ':'fromcom.intellij.gradle.toolingExtension.impl.model.taskIndex.GradleTaskIndexBuilder.buildAll(GradleTaskIndexBuilder.java:39)Additionally, the project that this reproducer sample is based on also throws the same error from
com.intellij.gradle.toolingExtension.impl.model.taskModel.GradleTaskModelBuilder.buildAll(GradleTaskModelBuilder.kt:31)but for some reason I haven't determined yet, this reproducer sample doesn't exhibit.The stacktrace line numbers in the configuration cache report also does not line up with the code in the repo for the tag that this version of Studio is based on. Here's where I think the stacktrace points to, both of which are blank lines:
Neither class calls
DefaultProject.getPropertiesas far as i can see in the source code in the links above.Full stacktrace from the configuration cache report (which I can't attach because it is 105MB)
And the other stacktrace from the other project where I have these issues