Any reasons why my compile time (Macbook Air M2) may have gone up significantly sometime over the last couple of months ?

[ThomasH99]

Sometime back I noticed that the compile time went up quite significantly from almost instantaneous (I haven't measured but maybe 10-20s) to something much slower around 1 minute 30.

I can also see that the compilation seems to run on a single cpu on the M2 (around 100%, sometimes up around 150%) but I never checked this before.

I think this started around the same time when the old compliance check was removed, but not sure if it coincides exactly.

So, I was wondering if something changed that could explain this show down (or if there is anything I could try to get the old speed back)?

Another info: I'm working on project created several years ago, so maybe I'm missing something in my configuration?

[shai-almog]

I'm on an M2 Air myself and bisected this using Claude to see if there was a regression, it didn't find anything, here's its report:

Method

I bisected against the 20 actual released plugin versions sitting in your ~/.m2 — 7.0.214 (Dec 15 2025) through 7.0.250 (Jun 5 2026), i.e. the reporter's whole window. For each version I held the app fixed and swapped only cn1.version/cn1.plugin.version, then timed mvn clean process-classes (2 offline runs, best wall-clock + Maven's own total). Fixture: a generated cn1app's common module bound to compliance-check — the goal present in every version and the one the reporter fingered ("old compliance check was removed").

Results

Compliance-check goal, 400 compute-heavy classes, across all 20 versions:

version	maven total		version	maven total
7.0.214	3.39s		7.0.235	2.90s
7.0.223	3.86s		7.0.237	5.76s*
7.0.228	3.57s		7.0.242	4.94s*
7.0.230	3.52s		7.0.243	3.86s
7.0.231	2.52s		7.0.247	2.88s
7.0.233	3.69s		7.0.250	3.42s

Flat. 7.0.250 (3.4s) ≈ 7.0.214 (3.4s). The 237/242 blips are single-run noise, not a sustained step.

Scaling 400 → 2000 classes (current version): bytecode-compliance 0.82s → 1.82s (sublinear, 2.2× for 5× classes), css flat, javac 1.85s → 4.68s. No goal is super-linear.

Full package of a 2000-class app on current 7.0.250: total ~9.7s — javac 5.2s, bytecode-compliance 1.8s, css 1.5s, process-annotations 0.08s.

Verdict

There is no build-time regression between 7.0.250 and the past two months' versions. Across the whole ladder the compliance/build pipeline is flat-to-slightly-faster; nothing reproduces anything close to the reporter's 90s, and nothing scales pathologically. The reporter's compliance hypothesis specifically doesn't hold — on a tiny project the old ProGuard-based check actually had more fixed overhead than the new ASM one.

So the 10s→90s the reporter sees is project-specific, not a plugin version regression. Likely drivers, in order of suspicion:

• Their codebase / cn1lib dependency set — a years-old project may pull many .cn1libs; the new compliance indexes core + java-runtime + every dependency jar each build (a fixed cost that grows with dep count, not class count). My fixture only had core + java-runtime.
• Environment — clean vs incremental, antivirus/Gatekeeper on the M2, or JDK/network differences.
• A goal their updated pom now binds that I'm not exercising in the same proportion (their real resource/CSS set).

[ThomasH99]

Thanks! I have 274 files (this is the slow step: [INFO] Compiling 274 source files to /Users/user/myapp/common/target/classes), so well within the range you tested and at least it confirms that a compile time of over 90s is not normal.

I also checked with ChatGpt which suggested trying this time mvn -T 1C clean compile which only took about 10s! It gave the below output though.

Could there be any stuff left in (or left out of) an old project setup which could explain it? Or is there a way to force parallel build which is not in place for my project?

[WARNING] *****************************************************************
[WARNING] * Your build is requesting parallel execution, but project      *
[WARNING] * contains the following plugin(s) that have goals not marked   *
[WARNING] * as @threadSafe to support parallel building.                  *
[WARNING] * While this /may/ work fine, please look for plugin updates    *
[WARNING] * and/or request plugins be made thread-safe.                   *
[WARNING] * If reporting an issue, report it against the plugin in        *
[WARNING] * question, not against maven-core                              *
[WARNING] *****************************************************************
[WARNING] The following plugins are not marked @threadSafe in todocatalyst-common:
[WARNING] com.codenameone:codenameone-maven-plugin:7.0.250
[WARNING] Enable debug to see more precisely which goals are not marked @threadSafe.
[WARNING] *****************************************************************

[shai-almog]

Interesting. Try running mvn clean compile twice and give me the timings for both.

The second should be a bit faster, but I doubt we will see a 90 second to 10 second difference. Then compare that with exact timings to the -T version so we have a good baseline for comparison.

[ThomasH99]

First time mvn clean compile: Total time: 10.405 s
Second try: Total time: 17.024 s
Immediately after: time mvn -T 1C clean compile : Total time: 29.349 s (Wall Clock)
And then again: Total time: 25.444 s (Wall Clock)
Then time mvn clean compile again: Total time: 24.511 s

I then did a clean followed by "Run in simulator" and this time the compile step took around 20s.

So, not sure what goes on, clearly nothing to do with lack of parallel compilation. My gut feeling was that some changes to my code make the compilation longer, but with the initial clean that doesn't make sense.

I was wondering if it could be throttling, but ChatGpt disagrees (and I have nothing heavy running in the background, total cpu 20-30%).

Any suggestions would be welcome, because the times when it takes 90s you start scrolling something else and waste a lot more time ;-)

[shai-almog]

If it takes 90 seconds save the console log then we can compare it to a non-console log. I'm guessing the 90 second issue relates to a maven check for updates.

[ThomasH99]

I will track this. Yesterday when testing of course I couldn’t reproduce it ;-) However, I don’t think there’s anything in the console log which is different, it is simply that the compile step sometimes takes very long. Can I update the maven scripts to log the time it takes?

[shai-almog]

I didn't try it so I don't know but maybe the maven profiler extension will work?