<https://youtu.be/qBkyU1TJKDg?t=2529> <https://you...
# compose
f

https://youtu.be/qBkyU1TJKDg?t=2529

https://youtu.be/qBkyU1TJKDg?t=1249

Holy f***ing shit
😮 1
Okay I've just tried it an unfortunately it does not work or works very poorly. The example in that video is some orchestrated perfect-case.
I've tried it again and it worked very well. It's probably kotlin implicitly creating some methods when things changed in method bodies.
Wow, that's odd, deleting code that was completely unused somehow made it work better.
I retract all negative statements. This is the best thing since sliced bread. How the hell did you do this. Kotlin interpreter? That has it be it right?
👀 3
r
Bytecode interpreter
r
after my test, it still takes some time to compile, not as fast as in the video
c
For me it took about 4 seconds
l
in my usage of it, i’ve seen some variability of time to compile and deploy. sometimes it is well under 1s, other times it is ~3s. Overall, from my POV, it is fast enough that it crosses a certain threshold where i start writing code in a more “experimental” and “fearless” way that I find somewhat transformational in terms of how enjoyable writing compose is.
r
I wonder if 3s is explained by a GC pause or some poor IO
l
i’m not sure. could be a few things i think. live edit uses the analysis that the IDE has of your code, so i’ve noticed if you end up editing some code that might invalidate that analysis significantly, then the kotlin compiler will need to re-analyze a larger portion of code and that can take time. additionally, it seems like sometimes the queue can get backed up a bit if you make several “large” edits in rapid succession. (which might happen if you move braces around for instance). but other times it seems like the delay may be more related to the connection that the deploy agent has or something
f
@Leland Richardson [G] Ohhhh that's so smart. So would I be correct in saying 'it uses FIR directly' and that the new kotlin compiler should make it a lot faster?
s
But the timestamp (

t=2529

) of the video you’ve linked is around cloud run. I assume you’re all talking about live edit. Maybe you meant to link something more like here

https://youtu.be/qBkyU1TJKDg?t=1276

?
f
Yes, thank you @Stylianos Gakis, I don't know how I got the timestamp wrong
🙌 1
m
The timestamp was correct when I clicked your link yesterday. Maybe YouTube updated the stream VOD.
👍🏽 1
👍 3
s
I was getting super confused why we’re suddenly all very excited about cloud run in the #compose channel 😂
😂 2
l
@Fudge FIR is a rewrite of the kotlin compiler frontend, and which “frontend” is being used depends on which kotlin compiler is bundled with studio. In this case, i believe we are not using the new frontend but in the future it probably will. This should result in a speedup of the IDE analysis as well as total build times for kotlin projects in general. I would say that live edit probably won’t be too affected simply because the IDE already does a pretty good job at caching frontend analysis so the latency you observe in live edit already has most of the frontend cost subtracted (though there are cases where this isn’t true if you end up invalidating a lot of the type checking with the edit you just made). when you’re editing inside of a function body, you typically invalidate very little because you haven’t changed the public signature of anything
m
Is there any technical blog post/article available on how Live Edit works?
i
only shit it's really fast😅
l
@Marcin Wisniowski not currently but perhaps when its in a more stable state we will try and put one together! i think thats a good idea
😍 3
f
@Leland Richardson [G] yes i would love that, this is such a cool feature
c
Oh nice. I bet you my slowdowns are caused by file analysis like Leland said. I'm very much looking forward to the new kotlin frontend compiler (ive filed many bugs with the kotlin team about it) and basically all my issues are due to large files and a slow frontend compiler. Now that I know that live edit also uses that I will try to catch if the slowdowns occur in those cases. thanks @Leland Richardson [G]
f
@Colton Idle He's saying that live edit does not use the new FIR yet
c
Yeah. No one uses it yet because it's not out. 😁 I was just saying that it's nice to know it's related.
I have some files that take like 10 seconds for them to be analyzed for syntax highlighting. So it seems like those same files would have slow live edit as well.
l
@Colton Idle i’d be curious to know how it works for you under those conditions. i suspect that even on a file that large, a lot of edits that are just in the body of a function should still result in pretty quick turnaround. if thats not what you see though i’d be interested in understanding more and maybe even hopping on a call or something to understand more about whats going on. regardless, we have tried our best with live edit to come up with an underlying architecture that should still do relatively well with large code bases, as we don’t want live edit to be just really cool demo-ware, but actually useful, even on big apps
c
So far the biggest thing I can think of is that we basically have a separate module for our compose design system. In that design system module we basically have 3 files. Each file houses a different size of design component. Small, medium, and large. We do this because our design team broke out the design system into small medium and large components. But I was working in the medium file yesterday (which probably contains maybe 50 composables) and a simple text change or rounded corner dp change was taking about 5 seconds.
l
note that the first change is likely to take longer than subsequentt changes…. it was taking 5secs consistently?
c
Yes
l
it would be interesting to see if you just split one of those you’re editing into a separate file, but same module, and do the same edits…. see if it gets to be much faster. after first edit for instance i would expect editing strings to be a ~300ms turnaround from keystroke -> on screen
c
I just watched what's new in dev tools and it seems like the code preview pane can actually take longer for live edits vs a device/emulator. I guess I can try again, but I'm going to be filing some bugs tonight
l
oh were you trying this with preview?
c
I did with preview and then I also did on device but the device kept flickering, almost like an entire activity was restarting. So I wasn't actually really able to test on device.
l
yes - right now live edit on device will cause a full-hierarchy recomposition for every edit
👀 1
but we are working on a solution which only recomposes the part of the hierarchy you’re editing, which will get rid of that flickering
its not restarting the activity, but it is doing a fully new composition of wherever your composition roots are
c
Aha. Yeah. I basically have two apps. And both flicker. 1. (The one I'm talking about now) the entire screen flickers and gets a full screen modal essentially because of the way (I guess) that we implemented a first time user experience. i.e. first time opening the app? Look at this carousel. 2. The second app flickers constantly because we have a bottom tab bar and an animation set on it so the entire thing flickers and animates in for like every keystroke
l
yep. these are understood issues with current approach and things we will be addrrssing with coming updates
c
Awesome!! Thanks Leland
Heard you were out on leave also. If so. Congratulations 🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉
l
im back now :) but yeah thanks, i have a little one to take care of now!
👶 5
👶🏽 1
💖 1
i
any link to track Live Edit source code?
👀 1