Joist was designed to start as quickly as possible, especially on large schemas that are typical of enterprise projects.
To achieve the fastest possible startup time, Joist avoids runtime bytecode generation (see shims and aliases). So instead of re-generating potentially several hundred classes (for large schemas) with CGLIB or ASM on each startup, all of Joist’s persistence hooks and meta-data are regular, static Java code that load quickly.
For example, running 1 JUnit test to save an
Address object on a ~200-table schema:
Joist starts 94% faster than Hibernate on this large, ~200-table schema.
Most of the remaining startup time, ~0.3 seconds worth, is the database connection/pool getting established, so it is unlikely to go away.
The first test is just inserting 1 object-per-commit, X number-of-times:
For this, Joist and Hibernate are pretty similar.
The next test is inserting X objects-per-commit:
Joist is ~60-70% faster than Hibernate when bulk-inserting items.
(Technically Joist cheats here because, although both Joist and Hibernate use the PostgreSQL sequences for id generation, Joist grabs all of the new entity ids with one bulk SQL statement while Hibernate uses 1-query-per-entity.)
Finally, updating X objects-per-commit:
Joist is ~30% faster than Hibernate when bulk-updating items.