Operating System: All
Platform: All

Attachment netvirt-mvn-o-Pq-clean-install.jfr.7z has been added with description: Oracle Java Mission Control JFR profiling of "mvno -o -Pq clean install" in netvirt on latest netvirt master today (65fb44e) with export MAVEN_OPTS="-Xmx4096m -Xverify:none"

> raise this with the Xmen (Xtend community), to see what they have to say

==> https://bugs.eclipse.org/bugs/show_bug.cgi?id=427909

any updates on this? Thanks.

Martin, thanks for the ping - it's sometimes useful to get reminders...

Dug a little more into this today. In https://git.opendaylight.org/gerrit/#/c/47036/, I'm introducing a proposed new "yang.skip.javadoc" system property, which if true skips the generation of those "verboseClassComments" for 'generated classes will include javadoc comments which re useful for users' with the "This class represents the following YANG schema fragment defined in module ...".

The results are too small to be significant on a single project, but on a multi-module reactor as small as e.g. netvirt/vpnservice this looks very interesting, and makes me thing I'm onto something that is worth digging more into, check this out:

netvirt/vpnservice:
mvn -o -Pq clean package: Total time: 03:14-21 min
mvn -o -Pq -Dyang.skip.javadoc=true clean package: Total time: 02:15-18 min

At the scale of a full ODL (autobuild), this would obviously likely be even more significant.

I'll use this as motivation to reach out to eclipse.org friends about https://bugs.eclipse.org/bugs/show_bug.cgi?id=427909. In the mean time, if we would get https://git.opendaylight.org/gerrit/#/c/47036/ into ODL (and I would follow with an oldparent change to leverage this IFF -Pq), that would probably be something useful in the very short term already.

Michael, is this still being worked on?

> Michael, is this still being worked on?

Robert, yup it is; this is proceeding on two levels, as outlined above:

a) https://git.opendaylight.org/gerrit/#/c/47036/ for short-term

b) https://bugs.eclipse.org/bugs/show_bug.cgi?id=427909 for medium term. I've actually discussed that with Sven Efftinge (AKA Mr. Xtext & Xtend..) at EclipseCon just last week! I've demonstrated the problem, and convinced him that there is one, which is always a good first step.. We attempted a 5' quick fix together (replacement of an ArrayList by a LinkedList), but saw that was no good, and that Xtend lib StringConcatenation would need more than 5' of work. If I have nothing else on my pile, I may spend a bit more time on it, but it's not a high priority for me, given that we have a short-term work around.

yeah, it's maybe 30 minutes – if that protected splitter method can be made non-public If it needs to be retained, you are in a pickle...

Attachment xtextlib.diff has been added with description: prototype dirty fix

Robert, as per private email exchange, I've tested your "prototype dirty fix" (above), fixed what we agreed in email was left in there but you meant to remove, and done a few other things in StringConcatenation orthogonal to your change, which in my measurements have an additional measurable positive impact; see https://bugs.opendaylight.org/show_bug.cgi?id=6236 for full details, and https://github.com/eclipse/xtext-lib/pull/16/files for the proposed combined change. It's a step, but somehow I'm not entirely satisfied - still hot spot, when the goal should be to not have any in three.. Please do shout if you see any potential for further improvement?

I've attempted to try out the full scenario from above with this fix, by replacing the x3 xtext/xbase/xtend (except xtend-maven-plugin) 2.9.2 in odlparent with locally built 2.11.0-SNAPSHOT:

An "mvno -o -Pq clean install" in netvirt/vpnservice seems to go from approx. 3:07 down to 2:40, so 27s gained (BTW with a master 2.11.0-SNAPSHOT without changes it's still 3:06; tested).

That's something, and reason enough for me to keep suggesting to Xtend to do something about this, on their side. For us in ODL in the short term though, as even this gain, if they accept it, when we upgrade, is still less than the more significant 1’ gain seen earlier above when just completely skipping Xtend with https://git.opendaylight.org/gerrit/#/c/47036/. My suggestion would thus be that we integrate c/47036 anyway.

PS: When I JMC profile mvn then the hotstop still looks like the old one, so I doubted for a moment whether the lib switch from 2.9.2 to 2.11.0-SNAPSHOT even worked.. but as there is a measurable difference, that must be something else - the most likely explanation I have is that perhaps the test YangTemplateWithoutAnyDependencies.xtend doesn't lead to the exact same result as our "real" YangTemplate.xtend?

Another performance improvement for codegen to not emit empty indentation strings: https://bugs.eclipse.org/bugs/show_bug.cgi?id=507077

https://git.opendaylight.org/gerrit/#/c/48290/

Hi Michael

I guess this can be closed as RESOLVED FIXED, right?

> I guess this can be closed as RESOLVED FIXED, right?

I would suggest to keep it open until a new Xtend version 2.11 including our (Robert's) fixes is released, and then switch to it, and retest.. According to https://typefox.io/xtext-2-11-beta-1-is-here, "The Xtext 2.11 release has been rescheduled for January 24th 2017."

boron backport: https://git.opendaylight.org/gerrit/49234

The rest should be handled by odlparent upgrading to xtend to 2.11 once it is out.

> boron backport: https://git.opendaylight.org/gerrit/49234

OK but in that case, also https://git.opendaylight.org/gerrit/#/c/49235/

The workarounds have been delivered to Boron-SR3, upstream patches have been accepted and will be part of xtend-2.11, which is scheduled to release on Jan 24.

Targeting for M4 for the corresponding version bump.

xtext release has been delayed, we will probably not make it to M5.

patch to bump to 2.11.0.RC2: https://git.opendaylight.org/gerrit/51185

final bump: https://git.opendaylight.org/gerrit/51357