Reduce time required to generate the project accessors #1199
Conversation
The current one, based on the Kotlin compiler, and the challenger, emitting the bytecode for the accessors directly.
This makes code generation faster by a factor of 100 which means it now takes a few dozen milliseconds rather than a few seconds.
So the classpath for non-inlined accessors can be injected in the script ClassLoaders.
They served their purpose and now are in the way.
For it makes the script classloading cache integration test fail due to being too resource hungry.
So they are usable within the `configurations` block.
…ependency>)` accessor
by creating less intermediate collections Signed-off-by: Paul Merlin <paul@gradle.com>
|
One of the concerns I have about adding this feature is that it significantly raises the barrier to entry to adding new generated code to the project as an outside contributor. Any developer that doesn't know how to write JVM bytecode directly will be unable to contribute meaningful fixes or additions. Do you have any ways that this impact can be minimized? Perhaps allowing new features to be added without a bytecode component and adding bytecode generation when it's found that the performance increase is necessary? I just want to make sure the external contribution component of this change is considered. |
As it would require a few more annotations on `Action<*>` parameters and it adds overhead to script compilation.
To account for failures happening after all the work has been enqueued.
bamboo
changed the title
by limiting private members visibility Signed-off-by: Paul Merlin <paul@gradle.com>
by limiting private members visibility Signed-off-by: Paul Merlin <paul@gradle.com>
There was a problem hiding this comment.
I think this is good to merge, left one request on some test. There are things to improve, I'd say the main ones are i/o handling, split of the byte code emitter in logical chunks to make it more easier to work with (eg. schema -> Accessors -> Fragments -> source & bytes), and, deduplication of some source generation (kotlinDslAccessorsReport). Please capture those and the ones I missed in an issue.
| ): T = dependency.also { action.execute(it) } | ||
|
|
||
|
|
||
| class AccessorBytecodeEmitterSpike : TestWithTempFiles() { |
There was a problem hiding this comment.
❌ rename to eg. KotlinMetadataTest?
|
@JLLeitschuh, I agree this makes contributing new accessors a bit harder. But I think it's not as bad as it sounds. A proposal for new accessors should start with some example source we all can copy and paste in our build scripts and try. The next step is to turn that into a source template we can generate, with its inputs. The only thing this PR changes is adding the bytecode generation. Accessors should be lean, the complex things being done by the Gradle model. Their source should be short, so should their bytecode. We can collaborate on writing that short but tedious part. DSL extensibility and collections elements are good because we can reuse them a lot, uniformly. For example, your PR to add accessors to extensions of We should also make the code simpler to work with. There's room for improvement, see my review comment above for some first steps. |
By emitting the relevant bytecode directly instead of calling the Kotlin compiler to do it.