Hello Adam, I'll go with Joachim's opinion, doubting that your endeavour will actually lead to any significant benefits. Here are a couple of thoughts:
> If you call intern() on each primary/foreign key value when you retrieve it > from the ResultSet [...] Interning 50'000 transaction IDs seems like a very bad idea to me. A UUID string has 20 chars, i.e. a String representation of char[] with length 20, i.e. 40 bytes + 2 hash values (String.hash and String.hash32) = 48 bytes. That makes around 2.5MB of PermGen space occupied forever by a single SELECT statement (not counting other elements of class instance overhead). Let's assume you have 1000 users in your system, all with comparable amounts of transactions. That's 2.5GB of PermGen space occupied only with interned transaction IDs. It won't be long and your system will crash with OutOfMemoryExceptions. At the same time, interning IDs takes some time, as IDs are - by nature - unique. So you might not benefit much from this operation anyway. Do note that I'm mainly expressing doubts about interning primary key values (transaction IDs). I can see your point for interning foreign key values (account IDs). > the keys will be internalised and only one copy will be created (JVM 6 - in > the permanent generation / JVM 7 - on the heap). I wasn't aware that J2SE 7 changed its behaviour here. Can you cite any authoritative resource? > As far as the measurements/benchmarks are concerned the memory savings could > be quite significant but this obviously depends on the entity model. > To measure performance impact is not straighforward but I could have a go at > it at some point. Yes, I clearly wouldn't pursue this idea any further without significant evidence. > Could you give me some pointers where to look in the jOOQ > for the ResultSet -> entity translation code? The relevant code in jOOQ 2.6.2 is in FieldTypeHelper.getFromResultSet(). Beware though, that many JDBC drivers already pre-load the entire result set into memory, which means that your internalisation attempts might need to be pushed down into the JDBC driver to get a maximum effect. I do agree that org.jooq.Result might be improved by maintaining dictionaries of String data (or Integer, Long data, etc) for all columns that participate in a foreign key relationship. Again, benchmarks would need to prove first, if such an improvement would lead to significant gains in memory consumption - without significant loss of CPU time when loading results. I want to stress the fact, that keeping dictionaries on a per-result basis is probably much better than using global and eternal ID dictionaries in Java's PermGen space. Anyway, your suggestion made me think that, perhaps, catalog/schema/table/column names of generated artefacts should be interned. While these names make up little space, they are used a lot when accessing record values by field reference. There had been a couple of recent discussions about this. E.g. https://groups.google.com/d/topic/jooq-user/abER3uONFvI/discussion I'll register this as #2166 https://github.com/jOOQ/jOOQ/issues/2166 Cheers Lukas -- 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]. For more options, visit https://groups.google.com/groups/opt_out.
