Guten Tag Lukas Eder, am Sonntag, 4. Oktober 2020 um 14:16 schrieben Sie: > https://github.com/quarkusio/quarkus/issues/7440 and here: > https://github.com/jOOQ/jOOQ/issues/8779
These links read very interesting and are indeed what I hoped to find, thanks! > - jOOQ's DSL isn't very small in terms of byte code size.[...] Which tells me it consumes a "lot of memory" on runtime even for unused things, correct? Do you have an absolute number like 1 MiB or 10 or 100? I really don't have any feeling about how much memory we talk here. With my Raspi-powered PoC, I hosted Tomcat+Axis2 and stuff like that and 128 MiB of RAM weren't enough anymore, but I didn't try e.g. 256 MiB RAM and Tomcat+Axis2 might not used as well. > - The runtime overhead of building *every* query dynamically might be too > much. [...] https://github.com/jOOQ/jOOQ/issues/8320 Caching would definitely make sense for some queries, especially the ones simply storing telegrams. > [...]It would be > interesting to be able to construct jOOQ queries either on this server, and > then ship the query strings to your ARM-based environment (I'm aware of a > customer who does this, for entirely different reasons), or use some way > generate jOOQ queries at build-time, shipping the SQL statements in a file. If at all, the latter would better fit my use case, but it's difficult to decide currently if some intermediate file format would be of any benefit. Those files would need to be read as well and decided if to keep them in memory or alike. How would that compete with generating queries at startup time of some device/app and caching jOOQ-instances for queries itself in memory? The files in theory could be mapped into memory only and file system cache would optimize things, while jOOQ- instances would always need to be available in memory. Difficult and only worth it if really every CPU-cycle or bit of RAM counts I guess. > In fact, I have thought about offering such tooling in the past. It would > be really interesting to do all the SQL generation work at compile time, > and then produce type safe JDBC (or R2DBC, etc.) wrapping logic, including > the logic that maps query results to POJOs. Perhaps something similar to > SQLDelight, but more powerful. > Would that be something like what you had in mind? When it comes to optimization, yes. But as said, I'm not sure where I need to optimize right now at all, e.g. CPU cycles or RAM or I/O to read files or ... What I somewhat know is that my use case needs to INSERT a lot and when it comes to reading, it's e.g. often about comparing timestamps to decide if to INSERT at all or simply reading bulk inserted binary blobs to forward them somewhere else. So, I wouldn't benefit too much from reading into POJOs, but caching my queries should really be possible, as they are not too dynamic at runtime at all. Whatever tooling you have in mind, it might be a good idea to consider things like GraalVM native images. From my limited knowledge, that seems to execute static code or alike during the generation and that might be used by jOOQ as entry point to generate queries and cache them in memory. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: [email protected] AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...........05151- 9468- 55 Fax...............05151- 9468- 88 Mobil..............0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/1112904177.20201005130758%40am-soft.de.
