[JBoss JIRA] (ERT-550) Benchmark old and new JDT Indexers
by Roland Grunberg (JIRA)
[ https://issues.jboss.org/browse/ERT-550?page=com.atlassian.jira.plugin.sy... ]
Roland Grunberg edited comment on ERT-550 at 11/28/17 1:18 PM:
---------------------------------------------------------------
Commented on jdt-core-dev asking for some clarification and it would seem that the new indexer is not intended to outperform the old one "across the board".
I am finding it difficult to produce cases where the new one outperforms the old one so I may have to keep trying later on.
Methadology :
See https://github.com/rgrunber/eclipse.jdt.core/tree/index_performance (should be top-most commit)
We take a set of jars, and split them (roughly) evenly among the number of projects to exist in the workspace. When then perform a type hierarchy search on java.lang.Object from one of the projects. The results are calculated from an average of 5 runs.
There's also testing of the actual time it takes to build the indexes but these seem pretty consistent across all scenarios. The new indexer is usually 2x as large and takes 3-4x as long to build.
Results so far for search indexing :
1 workspace project / 1500 jars / 43000 classes
Old : 5s
New : 22s
1 workspace project / 1 jar / 18000 classes
Old : 1s
New : 3s
1 workspace project / 1 jar / 24000 classes
Old : 2s
New : 7s
1 workspace project / 1500 jars / 75000 classes
Old : 7s
New : 34s
10 workspace project / 1500 jars / 75000 classes
Old : 4s
New : 7s
100 workspace project / 1500 jars / 75000 classes
Old : 3s
New : 6s
1 workspace project / 4000 jars / 120000 classes
Old : 44s
New : 320s
10 workspace project / 4000 jars / 120000 classes
Old : 9s
New : 15s
100 workspace project / 4000 jars / 120000 classes
Old : 8s
New : 12s
The results do seem to indicate that the new indexer works much faster when the number of projects increases, but its improvements never seem to do better than the old indexer.
Notes / Definitions :
jars - referring to .jar files, so N jars is exactly that many jars on the filesystem
classes - this is the number of classes detected by the indexer, and doesn't correspond to total number of unique classes of all jars
was (Author: rgrunber):
Commented on jdt-core-dev asking for some clarification and it would seem that the new indexer is not intended to outperform the old one "across the board".
I am finding it difficult to produce cases where the new one outperforms the old one so I may have to keep trying later on.
Methadology :
See https://github.com/rgrunber/eclipse.jdt.core/tree/index_performance (should be top-most commit)
We take a set of jars, and split them (roughly) evenly among the number of projects to exist in the workspace. When then perform a type hierarchy search on java.lang.Object from one of the projects. The results are calculated from an average of 10 runs.
There's also testing of the actual time it takes to build the indexes but these seem pretty consistent across all scenarios. The new indexer is usually 2x as large and takes 3-4x as long to build.
Results so far for search indexing :
1 workspace project / 1500 jars / 43000 classes
Old : 5s
New : 22s
1 workspace project / 1 jar / 18000 classes
Old : 1s
New : 3s
1 workspace project / 1 jar / 24000 classes
Old : 2s
New : 7s
1 workspace project / 1500 jars / 75000 classes
Old : 7s
New : 34s
10 workspace project / 1500 jars / 75000 classes
Old : 4s
New : 7s
100 workspace project / 1500 jars / 75000 classes
Old : 3s
New : 6s
1 workspace project / 4000 jars / 120000 classes
Old : 44s
New : 320s
10 workspace project / 4000 jars / 120000 classes
Old : 9s
New : 15s
100 workspace project / 4000 jars / 120000 classes
Old : 8s
New : 12s
The results do seem to indicate that the new indexer works much faster when the number of projects increases, but its improvements never seem to do better than the old indexer.
Notes / Definitions :
jars - referring to .jar files, so N jars is exactly that many jars on the filesystem
classes - this is the number of classes detected by the indexer, and doesn't correspond to total number of unique classes of all jars
> Benchmark old and new JDT Indexers
> ----------------------------------
>
> Key: ERT-550
> URL: https://issues.jboss.org/browse/ERT-550
> Project: Eclipse Release Train
> Issue Type: Task
> Reporter: Roland Grunberg
> Assignee: Roland Grunberg
>
> Benchmark the old and new JDT Indexers to determine which should be favoured in various conditions.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ERT-550) Benchmark old and new JDT Indexers
by Roland Grunberg (JIRA)
[ https://issues.jboss.org/browse/ERT-550?page=com.atlassian.jira.plugin.sy... ]
Roland Grunberg commented on ERT-550:
-------------------------------------
Commented on jdt-core-dev asking for some clarification and it would seem that the new indexer is not intended to outperform the old one "across the board".
I am finding it difficult to produce cases where the new one outperforms the old one so I may have to keep trying later on.
Methadology :
See https://github.com/rgrunber/eclipse.jdt.core/tree/index_performance (should be top-most commit)
We take a set of jars, and split them (roughly) evenly among the number of projects to exist in the workspace. When then perform a type hierarchy search on java.lang.Object from one of the projects.
There's also testing of the actual time it takes to build the indexes but these seem pretty consistent across all scenarios. The new indexer is usually 2x as large and takes 3-4x as long to build.
Results so far for search indexing :
1 workspace project / 1500 jars / 43000 classes
Old : 5s
New : 22s
1 workspace project / 1 jar / 18000 classes
Old : 1s
New : 3s
1 workspace project / 1 jar / 24000 classes
Old : 2s
New : 7s
1 workspace project / 1500 jars / 75000 classes
Old : 7s
New : 34s
10 workspace project / 1500 jars / 75000 classes
Old : 4s
New : 7s
100 workspace project / 1500 jars / 75000 classes
Old : 3s
New : 6s
1 workspace project / 4000 jars / 120000 classes
Old : 44s
New : 320s
10 workspace project / 4000 jars / 120000 classes
Old : 9s
New : 15s
100 workspace project / 4000 jars / 120000 classes
Old : 8s
New : 12s
The results do seem to indicate that the new indexer works much faster when the number of projects increases, but its improvements never seem to do better than the old indexer.
Notes / Definitions :
jars - referring to .jar files, so N jars is exactly that many jars on the filesystem
classes - this is the number of classes detected by the indexer, and doesn't correspond to total number of unique classes of all jars
> Benchmark old and new JDT Indexers
> ----------------------------------
>
> Key: ERT-550
> URL: https://issues.jboss.org/browse/ERT-550
> Project: Eclipse Release Train
> Issue Type: Task
> Reporter: Roland Grunberg
> Assignee: Roland Grunberg
>
> Benchmark the old and new JDT Indexers to determine which should be favoured in various conditions.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ERT-550) Benchmark old and new JDT Indexers
by Roland Grunberg (JIRA)
[ https://issues.jboss.org/browse/ERT-550?page=com.atlassian.jira.plugin.sy... ]
Roland Grunberg edited comment on ERT-550 at 11/28/17 1:16 PM:
---------------------------------------------------------------
Commented on jdt-core-dev asking for some clarification and it would seem that the new indexer is not intended to outperform the old one "across the board".
I am finding it difficult to produce cases where the new one outperforms the old one so I may have to keep trying later on.
Methadology :
See https://github.com/rgrunber/eclipse.jdt.core/tree/index_performance (should be top-most commit)
We take a set of jars, and split them (roughly) evenly among the number of projects to exist in the workspace. When then perform a type hierarchy search on java.lang.Object from one of the projects. The results are calculated from an average of 10 runs.
There's also testing of the actual time it takes to build the indexes but these seem pretty consistent across all scenarios. The new indexer is usually 2x as large and takes 3-4x as long to build.
Results so far for search indexing :
1 workspace project / 1500 jars / 43000 classes
Old : 5s
New : 22s
1 workspace project / 1 jar / 18000 classes
Old : 1s
New : 3s
1 workspace project / 1 jar / 24000 classes
Old : 2s
New : 7s
1 workspace project / 1500 jars / 75000 classes
Old : 7s
New : 34s
10 workspace project / 1500 jars / 75000 classes
Old : 4s
New : 7s
100 workspace project / 1500 jars / 75000 classes
Old : 3s
New : 6s
1 workspace project / 4000 jars / 120000 classes
Old : 44s
New : 320s
10 workspace project / 4000 jars / 120000 classes
Old : 9s
New : 15s
100 workspace project / 4000 jars / 120000 classes
Old : 8s
New : 12s
The results do seem to indicate that the new indexer works much faster when the number of projects increases, but its improvements never seem to do better than the old indexer.
Notes / Definitions :
jars - referring to .jar files, so N jars is exactly that many jars on the filesystem
classes - this is the number of classes detected by the indexer, and doesn't correspond to total number of unique classes of all jars
was (Author: rgrunber):
Commented on jdt-core-dev asking for some clarification and it would seem that the new indexer is not intended to outperform the old one "across the board".
I am finding it difficult to produce cases where the new one outperforms the old one so I may have to keep trying later on.
Methadology :
See https://github.com/rgrunber/eclipse.jdt.core/tree/index_performance (should be top-most commit)
We take a set of jars, and split them (roughly) evenly among the number of projects to exist in the workspace. When then perform a type hierarchy search on java.lang.Object from one of the projects.
There's also testing of the actual time it takes to build the indexes but these seem pretty consistent across all scenarios. The new indexer is usually 2x as large and takes 3-4x as long to build.
Results so far for search indexing :
1 workspace project / 1500 jars / 43000 classes
Old : 5s
New : 22s
1 workspace project / 1 jar / 18000 classes
Old : 1s
New : 3s
1 workspace project / 1 jar / 24000 classes
Old : 2s
New : 7s
1 workspace project / 1500 jars / 75000 classes
Old : 7s
New : 34s
10 workspace project / 1500 jars / 75000 classes
Old : 4s
New : 7s
100 workspace project / 1500 jars / 75000 classes
Old : 3s
New : 6s
1 workspace project / 4000 jars / 120000 classes
Old : 44s
New : 320s
10 workspace project / 4000 jars / 120000 classes
Old : 9s
New : 15s
100 workspace project / 4000 jars / 120000 classes
Old : 8s
New : 12s
The results do seem to indicate that the new indexer works much faster when the number of projects increases, but its improvements never seem to do better than the old indexer.
Notes / Definitions :
jars - referring to .jar files, so N jars is exactly that many jars on the filesystem
classes - this is the number of classes detected by the indexer, and doesn't correspond to total number of unique classes of all jars
> Benchmark old and new JDT Indexers
> ----------------------------------
>
> Key: ERT-550
> URL: https://issues.jboss.org/browse/ERT-550
> Project: Eclipse Release Train
> Issue Type: Task
> Reporter: Roland Grunberg
> Assignee: Roland Grunberg
>
> Benchmark the old and new JDT Indexers to determine which should be favoured in various conditions.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (JBIDE-25441) Problems with CDI Builder and scanning Jars which support Java 9
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25441?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-25441:
------------------------------------
Suggestion in the above post is to do this:
{quote}I think jandex should be upgrade to version 2.0.4.Final that should have this fixed.{quote}
Affected files are therefore:
{code}
jbosstools-base/common/plugins/org.jboss.tools.common.core/META-INF/MANIFEST.MF
jbosstools-base/common/plugins/org.jboss.tools.common.core/pom.xml
jbosstools-base/common/plugins/org.jboss.tools.common.core/src/org/jboss/tools/common/core/jandex/JandexUtil.java
(uses jandex 1.2.4.Final)
jbosstools-base/common/tests/org.jboss.tools.common.core.test/src/org/jboss/tools/common/core/test/JandexTest.java
jbosstools-javaee/batch/plugins/org.jboss.tools.batch.core/src/org/jboss/tools/batch/internal/core/scanner/BatchArchiveDetector.java
jbosstools-javaee/cdi/plugins/org.jboss.tools.cdi.core/src/org/jboss/tools/cdi/internal/core/scanner/lib/BeanArchiveDetector.java
(use org.jboss.tools.common.core.jandex.JandexUtil)
jbosstools-hibernate/plugins/org.jboss.tools.hibernate.runtime.v_4_3/META-INF/MANIFEST.MF
jbosstools-hibernate/plugins/org.jboss.tools.hibernate.runtime.v_4_3/pom.xml
(uses jandex 1.1.0.Final)
{code}
> Problems with CDI Builder and scanning Jars which support Java 9
> ----------------------------------------------------------------
>
> Key: JBIDE-25441
> URL: https://issues.jboss.org/browse/JBIDE-25441
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi, common
> Affects Versions: 4.5.1.Final, 4.5.2.AM1
> Reporter: Nick Boldt
> Fix For: 4.5.2.AM2
>
>
> As reported in https://developer.jboss.org/message/978446?et=watches.email.thread#978446:
> {quote}
> Setup:
> * Eclipse Oxygen 4.7.1
> * JBoss Tools 4.5.1.Final (also tested with latest development version 4.5.2.AM1)
> * An maven web application with certain dependencies
> ** So far, we found two dependencies, which lead to this jandex scaning error after upgrading to latest version
> ** org.apache.logging.log4j version 2.10.0
> ** org.ow2.asm version 6.0
>
> This leads to an CDI Builder IllegalStateException - see exception trace below.
> Both dependencies started support for Java 9, which seems to cause this exception.
>
> *Apache Log4j 2.10.0 released*: http://mail-archives.apache.org/mod_mbox/www-announce/201711.mbox/%3Cdf95...
>
> {code}
> !MESSAGE Errors running builder 'CDI (Contexts and Dependency Injection) Builder' on project 'Webapp'.
> !STACK 0
> java.lang.IllegalStateException: Unknown tag! pos=4 poolCount = 24
> at org.jboss.jandex.Indexer.processConstantPool(Indexer.java:665)
> at org.jboss.jandex.Indexer.index(Indexer.java:699)
> at org.jboss.tools.common.core.jandex.JandexUtil.createJarIndex(JandexUtil.java:56)
> at org.jboss.tools.common.core.jandex.JandexUtil.hasAnnotation(JandexUtil.java:104)
> at org.jboss.tools.cdi.internal.core.scanner.lib.BeanArchiveDetector.hasAnnotatedBeans(BeanArchiveDetector.java:276)
> at org.jboss.tools.cdi.internal.core.scanner.lib.BeanArchiveDetector.resolve(BeanArchiveDetector.java:203)
> at org.jboss.tools.cdi.internal.core.scanner.lib.ClassPathMonitor.detectBeanModule(ClassPathMonitor.java:150)
> at org.jboss.tools.cdi.internal.core.scanner.lib.ClassPathMonitor.process(ClassPathMonitor.java:106)
> at org.jboss.tools.cdi.core.CDICoreBuilder.build(CDICoreBuilder.java:215)
> at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:735)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
> at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:301)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304)
> at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:360)
> at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:383)
> at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:142)
> at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:232)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
> {code}
> {quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (JBIDE-25441) Problems with CDI Builder and scanning Jars which support Java 9
by Nick Boldt (JIRA)
Nick Boldt created JBIDE-25441:
----------------------------------
Summary: Problems with CDI Builder and scanning Jars which support Java 9
Key: JBIDE-25441
URL: https://issues.jboss.org/browse/JBIDE-25441
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: cdi, common
Affects Versions: 4.5.2.AM1, 4.5.1.Final
Reporter: Nick Boldt
As reported in https://developer.jboss.org/message/978446?et=watches.email.thread#978446:
{quote}
Setup:
* Eclipse Oxygen 4.7.1
* JBoss Tools 4.5.1.Final (also tested with latest development version 4.5.2.AM1)
* An maven web application with certain dependencies
** So far, we found two dependencies, which lead to this jandex scaning error after upgrading to latest version
** org.apache.logging.log4j version 2.10.0
** org.ow2.asm version 6.0
This leads to an CDI Builder IllegalStateException - see exception trace below.
Both dependencies started support for Java 9, which seems to cause this exception.
*Apache Log4j 2.10.0 released*: http://mail-archives.apache.org/mod_mbox/www-announce/201711.mbox/%3Cdf95...
{code}
!MESSAGE Errors running builder 'CDI (Contexts and Dependency Injection) Builder' on project 'Webapp'.
!STACK 0
java.lang.IllegalStateException: Unknown tag! pos=4 poolCount = 24
at org.jboss.jandex.Indexer.processConstantPool(Indexer.java:665)
at org.jboss.jandex.Indexer.index(Indexer.java:699)
at org.jboss.tools.common.core.jandex.JandexUtil.createJarIndex(JandexUtil.java:56)
at org.jboss.tools.common.core.jandex.JandexUtil.hasAnnotation(JandexUtil.java:104)
at org.jboss.tools.cdi.internal.core.scanner.lib.BeanArchiveDetector.hasAnnotatedBeans(BeanArchiveDetector.java:276)
at org.jboss.tools.cdi.internal.core.scanner.lib.BeanArchiveDetector.resolve(BeanArchiveDetector.java:203)
at org.jboss.tools.cdi.internal.core.scanner.lib.ClassPathMonitor.detectBeanModule(ClassPathMonitor.java:150)
at org.jboss.tools.cdi.internal.core.scanner.lib.ClassPathMonitor.process(ClassPathMonitor.java:106)
at org.jboss.tools.cdi.core.CDICoreBuilder.build(CDICoreBuilder.java:215)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:735)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:301)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:360)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:383)
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:142)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:232)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
{code}
{quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (JBIDE-25441) Problems with CDI Builder and scanning Jars which support Java 9
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25441?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-25441:
-------------------------------
Fix Version/s: 4.5.2.AM2
> Problems with CDI Builder and scanning Jars which support Java 9
> ----------------------------------------------------------------
>
> Key: JBIDE-25441
> URL: https://issues.jboss.org/browse/JBIDE-25441
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi, common
> Affects Versions: 4.5.1.Final, 4.5.2.AM1
> Reporter: Nick Boldt
> Fix For: 4.5.2.AM2
>
>
> As reported in https://developer.jboss.org/message/978446?et=watches.email.thread#978446:
> {quote}
> Setup:
> * Eclipse Oxygen 4.7.1
> * JBoss Tools 4.5.1.Final (also tested with latest development version 4.5.2.AM1)
> * An maven web application with certain dependencies
> ** So far, we found two dependencies, which lead to this jandex scaning error after upgrading to latest version
> ** org.apache.logging.log4j version 2.10.0
> ** org.ow2.asm version 6.0
>
> This leads to an CDI Builder IllegalStateException - see exception trace below.
> Both dependencies started support for Java 9, which seems to cause this exception.
>
> *Apache Log4j 2.10.0 released*: http://mail-archives.apache.org/mod_mbox/www-announce/201711.mbox/%3Cdf95...
>
> {code}
> !MESSAGE Errors running builder 'CDI (Contexts and Dependency Injection) Builder' on project 'Webapp'.
> !STACK 0
> java.lang.IllegalStateException: Unknown tag! pos=4 poolCount = 24
> at org.jboss.jandex.Indexer.processConstantPool(Indexer.java:665)
> at org.jboss.jandex.Indexer.index(Indexer.java:699)
> at org.jboss.tools.common.core.jandex.JandexUtil.createJarIndex(JandexUtil.java:56)
> at org.jboss.tools.common.core.jandex.JandexUtil.hasAnnotation(JandexUtil.java:104)
> at org.jboss.tools.cdi.internal.core.scanner.lib.BeanArchiveDetector.hasAnnotatedBeans(BeanArchiveDetector.java:276)
> at org.jboss.tools.cdi.internal.core.scanner.lib.BeanArchiveDetector.resolve(BeanArchiveDetector.java:203)
> at org.jboss.tools.cdi.internal.core.scanner.lib.ClassPathMonitor.detectBeanModule(ClassPathMonitor.java:150)
> at org.jboss.tools.cdi.internal.core.scanner.lib.ClassPathMonitor.process(ClassPathMonitor.java:106)
> at org.jboss.tools.cdi.core.CDICoreBuilder.build(CDICoreBuilder.java:215)
> at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:735)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
> at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:301)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304)
> at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:360)
> at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:383)
> at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:142)
> at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:232)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
> {code}
> {quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months