Incremental annotation processor and processor optimizations #972
Conversation
2ea8b2d to
2cfa587
Compare
|
|
||
| // JavacFiler does not properly synchronize its "Set<FileObject> fileObjectHistory" field, | ||
| // so parallel calls to createSourceFile can throw concurrent modification exceptions. | ||
| val filerSourceFile = synchronized(filer) { |
There was a problem hiding this comment.
Do all processor get the same instance of filer? Probably doesn't matter as I don't think processors will be run concurrently
| validateAttributesImplementHashCode(generatedModels) | ||
| } | ||
|
|
||
| logger.writeExceptions() |
There was a problem hiding this comment.
Probably not necessary but just a thought - it seems like normal exceptions are pretty tractable and likely can be gracefully lazily collected.
Did you find any super weird output with concurrent exceptions like cme's while working on the parallelization? I could imagine that those might leave the program in a weird state and create tons of exceptions. Specially handling them might also be nice to print a message like "CME found, consider disabling experimental parallelization feature and file a ticket with info).
There was a problem hiding this comment.
interesting idea. I did find CME sometimes, or a specific exception from ClassReader. i like the idea of checking for that to tell users to disable parallelization and to report the stacktrace. i didn't find any times where the processor got into a weird state because of it where there were downstream errors
| abstract val usesPackageEpoxyConfig: Boolean | ||
| abstract val usesModelViewConfig: Boolean | ||
|
|
||
| override fun supportedAnnotations(): List<KClass<*>> = mutableListOf<KClass<*>>().apply { |
There was a problem hiding this comment.
nit: Maybe a little safer to make this final, and have an abstract additionalSupportedAnnotations as it seems like we can't use @CallSuper or something like that
|
|
||
| /** | ||
| * Returns all of the package config elements applicable to this processor. | ||
| * |
| * The elements that influence the generation of this model. | ||
| * eg base model class for @EpoxyModelClass, view class for @ModelView, etc | ||
| */ | ||
| open fun originatingElements(): List<Element> { |
There was a problem hiding this comment.
Similar - might be nice to keep this private and call into an abstract originatingElements methods
|
I've pushed a |
|
Thank you a lot for this optimization! |
Fixes #423
logEpoxyTimingscan be set to get a detailed breakdown of how long the processors took and where they spent their time (off by default)enableParallelEpoxyProcessingcan be set to true to have the annotation processor process annotations and generate files in parallel (via coroutines). This can greatly speed up processing time, but given the nature of parallel processing it is still incubatingWith these optimizations and parallel processing, clean builds of a model with 165 @ModelView classes went from 4 seconds to 0.5 seconds. A module with 70 @EpoxyModelClass annotated classes also had a 27% decrease in processing time, also now to 0.5 seconds. We don't yet have any profiling for how much difference the incremental compilation makes, but these other optimizations are likely more impactful.
I will release this as a beta with a major release number