Fixed
Status Update
Comments
mo...@google.com <mo...@google.com>
mo...@google.com <mo...@google.com> #2
That seems quite bad :/ weird.
We have fairly large test projects which do not take anywhere close to it, maybe your code is triggering some bad code path.
Can you provide a sample or share your project with us? It is impossible to do something here unless we have a reproduction case. Might also possibly be related to your machine configuration.
We have fairly large test projects which do not take anywhere close to it, maybe your code is triggering some bad code path.
Can you provide a sample or share your project with us? It is impossible to do something here unless we have a reproduction case. Might also possibly be related to your machine configuration.
va...@google.com <va...@google.com> #3
Let me see what I can do on the reproduction as I am anyways blocked on this. I will try to extract out the DB module in a new project and see if it reproduces the issue.
va...@google.com <va...@google.com> #4
Attaching the sample project. When I run the project through the android studio or even command line, I see the described issue.
Try uncommenting room-compiler dependency from app's build.gradle, it does not have the issue because room compiler is not at work.
Try uncommenting room-compiler dependency from app's build.gradle, it does not have the issue because room compiler is not at work.
jb...@google.com <jb...@google.com> #5
Did you get a chance to look at it?
jb...@google.com <jb...@google.com> #6
FYI. I see that if I comment out applying google-services plugin (at the end of the app's build.gradle file), that fixes the issue too. Hence, you may need to apply a google-services plugin with a json file to reproduce the issue.
Not sure what is going on but certainly, somethings are not playing well together.
Not sure what is going on but certainly, somethings are not playing well together.
ap...@google.com <ap...@google.com> #7
Above comment is NOT TRUE, it seems I did not do a code change after commenting out apply google-services plugin. That's why the build passed.
jb...@google.com <jb...@google.com> #8
Thanks for the sample app. I haven't gotten to the bottom of the issue yet but I wanted to give you an update and it does seem indeed that Room is taking a very long time to parse and understand your queries via the ANTLR generated parser that Room uses. I'm not sure what is so special about your queries that is causing this, but I'll comment back with an update once I find out. Sadly for now I don't have a recommendation on a workaround.
mo...@google.com <mo...@google.com>
mo...@google.com <mo...@google.com> #9
Alright, I've drill down the problem to being the various "OR <col_name> LIKE '%' : text '%'" in your queries. Specifically they cause the SQLiteParser in Room to go down a path with poor performance as described in https://github.com/antlr/antlr4/issues/1398 . A fix for this involves updating Room's ANTRL runtime library and generated parser code with the latest version. This update will likely be available in Room 2.1.0-alpha02.
mo...@google.com <mo...@google.com> #10
Thanks for the update. Is 2.1.0-alpha02 around the corner?
ap...@google.com <ap...@google.com> #11
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 8e46b9ca1f55b040a18dd86833880b5106d103b2
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Wed Oct 10 19:17:50 2018
Update Room's ANTLR Parser to 4.7.1
Updating to the latest ANTLR version fixes the performance issue
described inhttps://github.com/antlr/antlr4/issues/1398 which affects
Room's SQL Parser since it contains left-recursive rules. Specifically
SQLite.g4 has multiple recursions to describe an expression as defined
inhttps://www.sqlite.org/lang_expr.html , meaning if a user has certain
queries that causes the parser to use the adaptivePredict algorithm
then the build time increases significantly due to Room's query
parsing.
Also bumped Room's version to 2.1.0-alpha02
Bug: 117401230
Test: ./gradlew room:integration-tests:testapp:cC
Change-Id: I4d0799a11ccee816ab209cbf74e7dcf2b2ce1a18
M buildSrc/src/main/kotlin/androidx/build/LibraryVersions.kt
M buildSrc/src/main/kotlin/androidx/build/dependencies/Dependencies.kt
M room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/dao/UserDao.java
https://android-review.googlesource.com/786077
https://goto.google.com/android-sha1/8e46b9ca1f55b040a18dd86833880b5106d103b2
Branch: androidx-master-dev
commit 8e46b9ca1f55b040a18dd86833880b5106d103b2
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Wed Oct 10 19:17:50 2018
Update Room's ANTLR Parser to 4.7.1
Updating to the latest ANTLR version fixes the performance issue
described in
Room's SQL Parser since it contains left-recursive rules. Specifically
SQLite.g4 has multiple recursions to describe an expression as defined
in
queries that causes the parser to use the adaptivePredict algorithm
then the build time increases significantly due to Room's query
parsing.
Also bumped Room's version to 2.1.0-alpha02
Bug: 117401230
Test: ./gradlew room:integration-tests:testapp:cC
Change-Id: I4d0799a11ccee816ab209cbf74e7dcf2b2ce1a18
M buildSrc/src/main/kotlin/androidx/build/LibraryVersions.kt
M buildSrc/src/main/kotlin/androidx/build/dependencies/Dependencies.kt
M room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/dao/UserDao.java
pr...@google.com <pr...@google.com> #12
No concrete date on 2.1.0-alpha02, I want to get a few more bugs in before making the next alpha release. So maybe by the end of the month.
Description
Component used: Transition Version used: 1.5.0-alpha02 Devices/Android versions reproduced on: API 34
If you do a gesture back in Fragments using transitions and cancel the gesture multiple times, after the first cancel, starting the gesture will result in the transition on the exiting view failing to run.
I believe the cause of this is that the this
beginDelayedTransition()
called by with a 0 duration called by Fragment never triggersonAnimatedEnd()
callback inVisibility
. That results in the visibility failing to be added removed from the overlay and so the subsequent transitions on the view do not run.Here are logs synced with the calls from Fragment and Visibility. I would expect there to be an
onAnimationEnd reversed=false
log before theonTransitionEnd
in Visibility.The can be reproduced by patching in aosp/2748867 and doing the following in the navigation-integration app :