How does use of reflection impact performance in JDXA ORM?

edited September 2016 in FAQs
Good question. One of the major driving force in designing our ORM framework was to keep it as much non-intrusive as possible. We did not want the framework to bite too deep into an app’s object model and the app’s general architecture. So we don’t impose any base class for persistence purpose. We even avoid annotations so that the model classes are kept totally “clean”. We also avoid code generation and usage of of the so called DAO classes.

Yes, our approach does introduce the cost of reflection. But we feel that if an app is not spending a major portion of its execution time in the data access layer (as compared to the combined time spent in the UI, network access, and business logic layers), the additional overhead of reflection may not matter that much in the overall performance of the app.

Moreover, JDX ORM (the underlying engine for the JDXA ORM for Android) has been designed to be highly efficient – it minimizes database trips, uses prepared statements where possible, uses connection pools, allows bulk operations, employs meta-data caching, and provides object caching. So we think that for most apps, the trade-off between dealing with a totally non-intrusive programming model offered by JDX vs. dealing with somewhat faster performance due to avoidance of reflection would work in favor of the non-intrusive programming model because of the resulting ease of development, evolution, and maintenance of those apps.
This discussion has been closed.