This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 243897 - Starting CoS unit tests extremely slow
Summary: Starting CoS unit tests extremely slow
Alias: None
Product: projects
Classification: Unclassified
Component: Maven (show other bugs)
Version: 8.0
Hardware: PC Linux
: P3 normal (vote)
Assignee: Milos Kleint
Depends on:
Reported: 2014-04-17 20:54 UTC by Jesse Glick
Modified: 2017-01-25 17:04 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

.npss file attached from NetBeans (338.75 KB, application/x-npss)
2014-04-17 20:54 UTC, Jesse Glick
.npss file attached from NetBeans (60.38 KB, application/x-npss)
2014-07-07 15:01 UTC, Jesse Glick

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2014-04-17 20:54:00 UTC
Product Version = NetBeans IDE Dev (Build 20140414-18a1c1d2d22e)
Operating System = Linux version 3.11.0-19-generic running on amd64
Java; VM; Vendor = 1.7.0_51
Runtime = Java HotSpot(TM) 64-Bit Server VM 24.51-b03

I have a unit test in a Maven project which I am trying to run repeatedly after making minor edits to sources and/or tests. Compile-on-Save mode is enabled, which is good because it skips most of the setup in the Maven process. Yet something like 20-30s elapse from the time when I press Ctrl-F6 to when “Scanning for projects...” actually appears in the Output Window! Some time elapses, then a wait cursor appears, then the wait cursor disappears and a process appears in the process list, and then eventually the Output Window opens and finally Maven starts running.

A profiler snapshot shows that BeanRunConfig.getMavenProject is called twice—from CosChecker, and from JUnitOutputListenerProvider—and each time it calls NbMavenProjectImpl.loadMavenProject (even though the code would lead you to believe this value is cached), and each call takes around 9s! Since I am not setting any special properties (besides -Dtest=…) or profiles, it seems gratuitous to be doing a quite expensive recalculation of the project model (twice) every time.
Comment 1 Jesse Glick 2014-04-17 20:54:27 UTC
Created attachment 146812 [details]
.npss file attached from NetBeans

.npss file
Comment 2 Milos Kleint 2014-04-20 19:15:29 UTC
as part of issue 168036, we've replaced EmbedderFactory.getOnlineEmbedder() with createProjectLikeEmbedder(). Please note that we're not reusing the project embedder but creating a new one which has a significant container initialization penalty. As far as I can tell, since maven 3.0.x, the problems of issue 168036 should not be present and reusing the existing embedder container should be safe.
Comment 3 Milos Kleint 2014-04-20 20:23:53 UTC
the two loadings of MavenProject are caused by subsequent calls to RunConfig.getMavenProject(). Unfortunately on different instances. Once on Runconfig passed to RunUtils.*, that instance is later "cloned" (an inheriting most properties from parent/source is used) in
Unfortunately copying the MavenProject mp field from parent to clone doesn't fix the issue as multiple checkers set properties on the clone or original thus resetting the mp field. With the assumption that changed profiles/properties invalidate the model. How far the assumption is correct in these cases remains to be examined. However with the right combination of getMavenProject() + setProperty() calls, we could end up with more than the observed 2 reloads.
Comment 4 Milos Kleint 2014-04-21 20:14:06 UTC

please test with your project.
Comment 5 Quality Engineering 2014-04-23 02:07:22 UTC
Integrated into 'main-silver', will be available in build *201404230001* on (upload may still be in progress)

User: Milos Kleint <>
Log: #243897 reuse project embedder, don't recreate. Also within MavenCommandLIneExecutor reuse the already loaded MavenProject instances, don't reset on property/profile change to prevent multiple loadings right before the build is executed.
Comment 6 Jesse Glick 2014-04-24 16:26:24 UTC
Much better.
Comment 7 Jesse Glick 2014-07-07 15:01:29 UTC
Still seeing a significant delay in 20140630-368fe2537540, though perhaps not as long as before. CosChecker.checkRunConfig is still triggering a call to loadMavenProject.
Comment 8 Jesse Glick 2014-07-07 15:01:42 UTC
Created attachment 147918 [details]
.npss file attached from NetBeans

.npss file
Comment 9 Milos Kleint 2014-07-07 22:54:56 UTC
(In reply to Jesse Glick from comment #7)
> Still seeing a significant delay in 20140630-368fe2537540, though perhaps
> not as long as before. CosChecker.checkRunConfig is still triggering a call
> to loadMavenProject.

Yes, but there should be only one such call. And that's correct AFAIK. The model for execution can differ from the one for loading (different profiles, properties) and the pre-build checkers need the correct thing to act upon.
Comment 10 Jesse Glick 2014-09-03 04:08:42 UTC
Unfortunately we are paying this price all the time even though it is rare for the aspects of the model which CosChecker would care about to actually be modified by things set in the run config (typically just -Dtest=…).
Comment 11 Martin Balin 2016-07-07 08:39:25 UTC
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss
Comment 12 markiewb 2016-07-10 20:35:21 UTC
Still valid in 8.2 dev 
Product Version: NetBeans IDE Dev (Build 201607100002)
Comment 13 Jesse Glick 2017-01-25 17:04:44 UTC
FWIW I have not seen this recently.