[
https://issues.apache.org/jira/browse/JENA-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222769#comment-16222769
]
Andy Seaborne commented on JENA-1407:
-------------------------------------
A comparison of the changes:
The machine is quad-core with hypterthreading (so 8 hardware threads).
Watching with gnome-system-monitor.
----
Running old-style (no old POM changes):
In the first test, BatchedTriGOutputTest, CPU use hops around for a short time
(expected, start-up), then maxes out one and only CPU at 100% smoothly, no
thread hoping showing.
Then it hits some fast tests and the usage is jumpy, typical of many small work
items.
When it hits TriXAsQuadsInputTest CPU drops to low, noise levels.
Slow tests have a small burst of CPU at the start, then nothing.
Compression adds a small amount to the CPU burst but still the majority of the
~1 min is no appreciable CPU use.
Conclusion: it is not compute bound, it is some sort of thread
scheduling/locking.
----
With threadCount=2 , parallel=classes
Long wait (~1min) until first Surefire message: one CPU maxed'ed out, smooth.
{noformat}
Running org.apache.jena.hadoop.rdf.io.registry.TestHadoopRdfIORegistry
{noformat}
Much better.
All 8 threads, 4 CPUs, are being used for a while then it drops off to zero for
the last minute or so of the test run.
----
With threadCount=1 , parallel=classes
(i.e. Surefire "one thread per core") I get much the thread behaviour as
threadCount=2, 8 threads in action. Maybe "core" = "hyperthread".
----
Some rough times:
||ThreadCount||Time||
|1|3m40s|
|2|2m45s|
|4|2m40s|
> Improvements to build/test time of Elephas tests.
> -------------------------------------------------
>
> Key: JENA-1407
> URL: https://issues.apache.org/jira/browse/JENA-1407
> Project: Apache Jena
> Issue Type: Improvement
> Reporter: Andy Seaborne
> Priority: Minor
> Attachments: Elephas-Test-Times
>
>
> The Elephas test can take a significant proportion of the total build time.
> if this could be improved without lost of testing, development and release
> work, building locally would be improved.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
