Generally speaking, generating one instance of something versus generating N is better. It has the potential to affect performance in regards to memory consumption in relation to the size of N
On Mon, Sep 25, 2017 at 7:12 AM Sanne Grinovero <sa...@hibernate.org> wrote: > On 25 September 2017 at 12:47, Steve Ebersole <st...@hibernate.org> wrote: > > I'm missing something. IIUC the discovery was that, e.g., having > something > > like `BaseHibernateSearchLogger` in module-A and then something like > > `RealLogger` in module-B that extends `BaseHibernateSearchLogger` causes > > extra space to be taken up within the VM memory space. Yet this is still > > exactly what you do. What am I missing? > > Good point. The problem is not "to not extend anything" but to not > extend another interface which also contains some hundreds of logging > messages you're not actually needing. > > I introduced the `BaseHibernateSearchLogger` for it to contain the > ones which I'd still want to share, at least for a little longer. In > an ideal cleanup this interface would be empty. > > > > > Out of curiosity, is this specific to WildFly/Modules and how it handles > > Class loading? Or is this something in the JVM itself? > > The JVM itself: it affects all our users. > It's interesting for WildFly too but mainly because a lot of libraries > composing WildFly do similar stuff. > > > > > Another thing I'd like to point out that I believe helps with > performance in > > regards to loggers is what I have been doing in ORM which is to use just > a > > single instance of named loggers, which you can see in the loggers in the > > `org.hibernate.internal.log` package : > > > https://github.com/hibernate/hibernate-orm/tree/master/hibernate-core/src/main/java/org/hibernate/internal/log > > I like that but especially in terms of user friendlyness. What makes > you think it would affect performance? > > And thanks for teaching me about @ValidIdRange, I didn't know that one :) > > Thanks, > Sanne > > > > > > On Mon, Sep 25, 2017 at 6:32 AM Sanne Grinovero <sa...@hibernate.org> > wrote: > >> > >> Our friend and colleague Andrew Dinn from the OpenJDK team is working > >> on a series of blog posts to help people understand the impact of > >> certain design choices on the cost of internal JVM metadata and native > >> memory; this affects bootstrap costs of both the JVM and our > >> libraries, overhead at runtime in terms of permanent memory waste, > >> etc.. > >> > >> So as these blogs will be out soon I'm not going to dive into more > >> details or how I discovered this, but as a draft reviewer I had the > >> privilege to already play with the technique and send a PR to > >> Hibernate Search as result of verifying some theories. > >> > >> In a nutshell Andrew's work allowed me to spot that having a Logger > >> interface in module A extended by another Logger in module B is > >> causing it to generate a significant amount of duplication of Class > >> definition metadata: the generated loggers are quite verbose in terms > >> of such costs and don't benefit from inheritance as one would expect: > >> the cost of B is (A+B), if you ignore benefits from symbol > >> de-duplication. In this specific example I could measure more than > >> 200K of wasted space. That's not small for a single jar! Incidentally > >> in this case it also bloats the jar file size. > >> > >> A code patch might be more clear to explain than emails; this is what > >> I recommend we do in all projects: > >> - https://github.com/hibernate/hibernate-search/pull/1546 > >> > >> N.B. the verbosity of the generated code is related with runtime > >> performance so I don't think we'll to remove the generated Logger > >> metadata, and certainly don't plan to switch logger implementations as > >> there are many more aspects to take into account - yet we might have > >> identified an anti-pattern which is multiplying this cost N times > >> without a good reason and it's quite easy and under our control to > >> avoid that. > >> > >> Thanks, > >> Sanne > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev@lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
