Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] Interesting tweet about perfs
I measured with Eclipse 2018-12 committer package which I use for JGit/EGit development
and couldn't find a significant difference by setting this system property.
It always takes between 7-7,5 seconds to start.

-Matthias

On Thu, Jan 24, 2019 at 5:33 PM Ed Merks <ed.merks@xxxxxxxxx> wrote:

I'm suspicious about such claims in general.  Perhaps something dramatic has changed in some particular unspecified JVM/JRE,  because most certainly such things have never showed up as a performance bottleneck of the magnitude suggested by this Bugzilla/tweet, and I've spent weeks in the past on platform startup performance and more than a week on Xcore performance last year.  So I expect there is an anomaly here. Also, I don't think we can just blindly set this and hope it works on all JREs:

    -Djavax.xml.parsers.SAXParserFactory=com.sun.org .apache.xerces.internal.jaxp.SAXParserFactoryImpl

And ans I mentioned specifically in that bug, that the one place he pointed at could avoid creating a parser in 99.999999% of the cases.


On 24.01.2019 17:24, Ed Willink wrote:

Hi

Great. That should be a really easy fix then. All these files are being opened by EMF, so EMF can cache the result of a first lazy System property read for the lifetime of the EMF plugin. Maybe it is an idiom that should be applied more universally, until Oracle fixes the bug.

(It might have an accidental further benefit to Xtext that can create huge numbers of EMF resources, one per Java type, hopefully without preparing a parser for each. I looked at https://bugs.eclipse.org/bugs/show_bug.cgi?id=543742 and it looks like a many resources not parser issue.)

    Regards

        Ed Willink

On 24/01/2019 16:06, Mickael Istria wrote:


On Thu, Jan 24, 2019 at 4:55 PM Ed Willink <ed@xxxxxxxxxxxxx> wrote:
[...]a faster parser[...]

According to the tweet, it's not about a faster parser. Also, the suggested value for the parser is actually the default one in most JVMs.
it's about explicitly defining the property seems to save time in resolving the abstract parser to a concrete one, as it "just" reads the system property and load the class instead of checking possible extensions/service providing this.

_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ide-dev

Virus-free. www.avast.com 

_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ide-dev
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ide-dev

Back to the top