# The Economics of Generated Code

DevFeed: [The Economics of Generated Code](<https://devfeed.tech/articles/the-economics-of-generated-code-20977.md>)

Original publisher: [Read original article](<https://jakewharton.com/the-economics-of-generated-code/>)

Published: 2019-03-26T00:00:00Z

Content type: article

Language: en

Sources: [Jake Wharton](<https://devfeed.tech/sources/jake-wharton.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [Library](<https://devfeed.tech/topics/library.md>), [Parsing](<https://devfeed.tech/topics/parsing.md>), [Polymorphism](<https://devfeed.tech/topics/polymorphism.md>), [JSON](<https://devfeed.tech/topics/json.md>), [API](<https://devfeed.tech/topics/api.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [code](<https://devfeed.tech/tags/code.md>), [json](<https://devfeed.tech/tags/json.md>), [library](<https://devfeed.tech/tags/library.md>), [parsing](<https://devfeed.tech/tags/parsing.md>), [polymorphism](<https://devfeed.tech/tags/polymorphism.md>)

## AI overview

The article explains the economics of generated code: because a generator is written once but its output is repeated many times, optimizing generated output can quickly repay the investment. It examines method-reference counts and shows how consolidating behavior in a runtime-library base class, then explicitly referencing the supertype method, can reduce hundreds of redundant references to one in an API model layer.

## Source excerpt

Among the many things that I've stolen learned from Jesse Wilson is the phrase "the economics of generated code". This captures the idea that the things we value when generating code are different than those we value for code that's manually written. A code generator is only written once but the code it generates occurs many times. Thus, any investment into making the generator emit more efficient code will pay for itself very quickly. This generally means output less code and allocate fewer objects wherever possible. I'd like to expand on that with two specific, real-world examples which I've run into. Extra Method References While it's not as much of a problem as it used to be, method reference count is still something worth keeping an eye on. This is especially true for generated code. Small changes in the generator can result in the count going up or down by the hundreds or thousands. It's common for generated classes to be a subtype of a class in the runtime library. Aside from facilitating polymorphism, this allows consolidating common utilities and behavior. Take a JSON model that wants to retain unknown keys and values encountered during parsing. Each generated class could maintain its own Map<String, ?> for the unknown pairs, but this is a great candidate for consolidation into a base class in the library. abstract class JsonModel { private final Map<String, ?> unknownPairs; public final Map<String, ?> getUnknownPairs() { return unknownPairs; } // ... } Not having a getUnknownPairs() method in each generated class should obviously reduce the count. But since the count is not just about declared methods, reducing the referenced methods in the generated code will also have an impact. Each generated class extends JsonModel and implements toString() which outputs its own fields and the getUnknownPairs() map. final class UserModel extends JsonModel { private final String name; private final String email; // ... @Override public String toString() { return "UserModel{