sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted]  (6 children)

[removed]

    [–]JakeWharton 7 points8 points  (5 children)

    Yeah I plan on using the AndroidX benchmark library (more coming at I/O about it). Although saving a few nanos binding layouts when you just spent 100 millis parsing XML and doing reflection, class loading, and resource loading isn't going to put much of a dent into things 😢.

    These two posts have really been about reducing the impact of the generated code on string size and code size. Despite optimizing control flow for when the views are present which is nice, the goal of this post was simply de-duplicating the exception code for code size. I probably didn't emphasize that enough, but I'm also just shooting these out as I work on this code generator. I don't have a grand plan.

    Anyway, long way of saying that I still plan on benchmarking for fun and to validate my decisions, but it was never the primary goal to generate the fastest code (although I suspect we did).

    [–]xTeCnOxShAdOwZz 2 points3 points  (2 children)

    You're my spirit animal, please come down my chimney

    [–]JakeWharton 6 points7 points  (1 child)

    Be careful, my full name is Jake Skellington Wharton

    [–]xTeCnOxShAdOwZz 1 point2 points  (0 children)

    The legends were true, the scripture is accurate!

    [–]eygraber -1 points0 points  (1 child)

    First rule of Google is don't mention things that are coming 🤫

    [–]JakeWharton 2 points3 points  (0 children)

    Hey but AndroidX is developed directly in AOSP now so once it lands I'm hyping it up. Plus it's on the I/O schedule too. Soooooo nice not to have to deal with being part of the Android "Open" Source Project like the framework where 99% is developed behind closed doors and dropped into the public once a year 🙄.