Re: Back from vacations, working on Value/Ava/Rdn/Dn
Update : as of this sunny sunday morning, there are 3 remaining failures in the integ test (all the other tests are passing for all the other modules). Those failures are related to the ordering of complex rdn : Rdn rdn1 = new Rdn( schemaManager, " cn = c + cn = b " ); Rdn rdn2 = new Rdn( schemaManager, " cn = b + cn = c " ); assertEquals( rdn1, rdn2 ); (btw, this was an ignored test in trunk) and the last failure is due to a LDAP v2 specific test : assertTrue( new Rdn( schemaManager, "oid.2.5.4.3 = azerty" ).equals( "2.5.4.3=azerty" ) ); I'm confident I'll be done with the API work tonite !
Re: Back from vacations, working on Value/Ava/Rdn/Dn
Le 05/05/16 22:56, Emmanuel Lécharny a écrit : > One more thing, I have run some performance tests on DN creation for the > old code and the new : > > Old DN parsing for 10 000 000 DN creations : > > delta new 1 RDN : 5.946s (dc=example) > delta new 2 RDNs : 9.738s (dc=example,dc=com) > delta new 3 RDNs : 12.324s (uid=,dc=example,dc=com) > delta new 4 RDNs : 16.438s (uid=,ou=people,dc=example,dc=com) > > New DN parsing for 10 000 000 DN creations : > > delta new 1 RDN : 3.491s (70% faster) > delta new 2 RDNs : 7.206s (35% faster) > delta new 3 RDNs : 8.489s (45% faster) > delta new 4 RDNs : 12.654s (30% faster) > > > I would assume a global 30% speedup, average. I haven't tested yet the > complex parser, but this is very encouraging ! > Complex parse is WAY WAY slower :/ Still it's 15% faster in the new code. Antlr is killing us here. We are talking of 45 000 DN parsed per second, compared to roughly 2.8 million per second ( 60 times slower...) !
Re: Back from vacations, working on Value/Ava/Rdn/Dn
Update : [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Directory LDAP API .. SUCCESS [ 2.344 s] [INFO] Apache Directory LDAP API I18n . SUCCESS [ 2.702 s] [INFO] Apache Directory LDAP API Utilities SUCCESS [ 4.224 s] [INFO] Apache Directory API ASN.1 Parent .. SUCCESS [ 0.337 s] [INFO] Apache Directory API ASN.1 API . SUCCESS [ 1.744 s] [INFO] Apache Directory API ASN.1 BER . SUCCESS [ 1.666 s] [INFO] Apache Directory LDAP API Parent ... SUCCESS [ 0.287 s] [INFO] Apache Directory LDAP API Model SUCCESS [ 15.314 s] [INFO] Apache Directory LDAP API Codec Parent . SUCCESS [ 0.301 s] [INFO] Apache Directory LDAP API Codec Core ... SUCCESS [ 3.876 s] [INFO] Apache Directory LDAP API Net Parent ... SUCCESS [ 0.301 s] [INFO] Apache Directory LDAP API Network MINA . SUCCESS [ 1.036 s] [INFO] Apache Directory LDAP API Extras ... SUCCESS [ 0.275 s] [INFO] Apache Directory LDAP API Extras Codec API . SUCCESS [ 1.228 s] [INFO] Apache Directory LDAP API Extras Codec . SUCCESS [ 2.779 s] [INFO] Apache Directory LDAP API Codec Standalone . SUCCESS [ 1.246 s] [INFO] Apache Directory LDAP API DSML Parent .. SUCCESS [ 0.276 s] [INFO] Apache Directory LDAP API DSML Parser .. SUCCESS [ 4.267 s] [INFO] Apache Directory LDAP API Extras ACI ... FAILURE [ 1.257 s] [INFO] Apache Directory LDAP API Schema Parent SKIPPED [INFO] Apache Directory LDAP API Schema Data .. SKIPPED [INFO] Apache Directory LDAP API Client Parent SKIPPED [INFO] Apache Directory LDAP API Client API ... SKIPPED [INFO] Apache Directory LDAP API DSML Engine .. SKIPPED [INFO] Apache Directory LDAP API Extras Util .. SKIPPED [INFO] Apache Directory LDAP API Extras Stored Procedures . SKIPPED [INFO] Apache Directory LDAP API Extras Trigger ... SKIPPED [INFO] Apache Directory LDAP API Schema Converter . SKIPPED [INFO] Apache Directory API All ... SKIPPED [INFO] Apache Directory LDAP API Client All ... SKIPPED [INFO] Apache Directory API Integration Tests . SKIPPED [INFO] Apache Directory API OSGi Integration Tests SKIPPED [INFO] Apache Directory LDAP API Distribution . SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] So the core of the work is now done (DN/RDN/AVA/Value are all fixed and made immutable), I have now to fix the places where we were using removed methods like getNormname(). It's going to be fast !
Back from vacations, working on Value/Ava/Rdn/Dn
Hi guys, sadly, I'm back... I wish I could still be in Greece, enjoying the spelndid weather. Anyway, last week-end, I was able to continue what I was working on : revamping the Value/Ava/Rdn/Dn classes, to make them immutable and to correctly deal with the various pb we had. One thing I realized while being far from my computer is that since day one (so 10 years ago), we have made a mistake : focusing on DN as if it was a String that needed to be converted to a data structure, instead of doing the opposite thing : it's a data structure that need to be converted to a String. It sounds silly, but it makes a hell lit of difference. The main thing is that the Value should always be a byte[] representing what the user put into it. Having a normalized form that is exposed for it is a non-sense. Actually, the normalized form is only useful when doing comparisons. This is the exact same thing for Ava, Rdn and Dn. At the end of the day, we just need to normalize on the fly, when we need to compare the value. That also mean we won't be able anymore to do things like : "0.9.2342.19200300.100.1.1=admin,2.5.4.11=system".equals( dn.getNormValue() ); but instead, we should do : dn.equals( "uid=admin,ou=system" ); or even better : dn.equals( ADMIN_DN ); assuming the ADMIN_DN value is a static Dn. When we need to use a Dn or a value in a Filter, we now need to call Dn/Rdn/Ava/Value.getEscaped() which returns the properly String representation of the element, with all the escaped chars that are required. Otherwise, making the various classes immutable simplify the work and the API. Atm, I've been able to rework the Value, Ava and Rdn classes, and the associated tests. I still have to make the Rdn class immutable (removing the apply(SchemaManager) method from it), and then the DN class. The next step will be to fix the API to use the simplified API. It's a bit of work, and I'll have to wait for the week-end to proceed, but I feel it's going to make it easier and more consistent in the long run. Last, not least, I have also greatly simplified the ComplexDnParser grammar. Antlr is not very cool when it comes to handle conflict... But anyway, I have it working now. More to come !
