[ http://opensource.atlassian.com/projects/hibernate/browse/HV-538?page=com... ] Hardy Ferentschik updated HV-538: --------------------------------- Fix Version/s: (was: 4.3.0.Alpha1) 4.3.0.next -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HV-538?page=com.atlassian.jira.plugin... ] Hardy Ferentschik commented on HV-538: -------------------------------------- Some observations from Gunnar: {quote} * The logging around Contracts#assertNotNull() caused very many invocations of String#format(), also if the asserted value actually was not null, as MESSAGES.mustNotBeNull( "bla" ) was passed as parameter. I've changed this by pushing the creation of the message into the actual null case [1]. * The logging generally causes invocations of String#format() which I think are are superfluous. More specifically format() is also invoked if a given log message doesn't have any parameters. AFAICS the message could directly be returned in that case. WDYT? I think we might create a ticket against LOGTOOLS for this. * When parsing mapping XML files, a new JAXBContext was created for each input stream. I think we can re-use the same instance for several input streams [2]. [1] https://github.com/gunnarmorling/hibernate-validator/commit/e5259254f8cd8... [2] https://github.com/gunnarmorling/hibernate-validator/commit/8a190275e9ed3... {quote} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HV-538?page=com.atlassian.jira.plugin... ] Gunnar Morling commented on HV-538: ----------------------------------- Options in case the cache turns out to be a bottle neck as proposed by Hardy: {quote} * try to improve the implementation (eg we could drop the hard ref part. then we could drop one of the _LRUMap_s which in turns means we could improve the get implementation to allow multiple readers (I think)) * look for another cache (even though I don't want to add a new dependency just for that) * revert back to a ConcurrentHashMap with the discussed problems of growth {quote} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HV-538?page=com.atlassian.jira.plugin... ] Hardy Ferentschik commented on HV-538: -------------------------------------- I also did some profiling and used the work I did for HV-100 to test different scenarios. Turns out _SoftLimitMRUCache_ is much slower than what we had before. For this reason I replaced _SoftLimitMRUCache_ w/ _ConcurrentReferenceHashMap_ - see https://github.com/hferentschik/hibernate-validator/tree/HV-538. WDYT? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HV-538?page=com.atlassian.jira.plugin... ] Hardy Ferentschik reassigned HV-538: ------------------------------------ Assignee: Hardy Ferentschik (was: Gunnar Morling) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HV-538?page=com.atlassian.jira.plugin... ] Hardy Ferentschik resolved HV-538. ---------------------------------- Resolution: Fixed -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira