I just noticed I didn’t update my compiler since 2023/03/03 and finally did so today. After making some required changes I noticed the compile times went down from basically instant (after being fully built once) to taking 4+ seconds every build.

Looking at the output it looks to me like it’s not loading the PPU files and recompiling nearly everything every time. Did something change I could investigate?

The only changes I needed to make were "Visibilities of members of generic specializations” from
https://wiki.freepascal.org/User_Changes_Trunk#Visibilities_of_members_of_generic_specializations but
that doesnt’ seem related.

Regards,
Ryan Joseph

I don’t know what causes this, but I have experienced the same issue. Just loading the IDE takes like 30 seconds on a version I installed in 2023 and another in early 2024, and those also compile much slower, but I just installed it again last week and the new version installed is fast again.. but if I run the ones from earlier they are still slow. I also note that when I run the slow versions, I can always exit out and run 3.2.2 and it’s almost instant.. so it’s not anything on my system. I’m doing my installs with FPCUPDeluxe. I did update that this last time so I’m not sure if that has anything to do with why it’s working so well now.

James

On Dec 4, 2024 at 6:22:12 PM, James Richters via fpc-pascal <

My only thought is that my project makes extensive use of multi helpers and implicit function specialization both of which were causing serious crashes in the compiler (I think they were the cause at least). I’m talking you change a top level file which all other files depend on and the compilers crashes on 5+ units which each need to be saved then recompiled to fix the crashes.

I wonder if they changed something regarding this. I searched for all commits with “helper” in them since my previous version and didn’t see anything which stood out to me but it’s hard to know.

I’m going to have to rollback and use my old version because it’s not usable like. Event going to 4 second build times if you change a single line is too painful.

When I have some time I’ll try to make a project which lots of multi helpers and see if those trigger crashes in the old compiler and maybe that’s a clue to the compiler people to know if they fixed this or not. Don’t know what else to do.

Regards,
Ryan Joseph

Hairy Pixels wrote

I’m going to have to rollback and use my old version because it’s not usable like. Event going to 4 second build times if you change a single line is too painful.

and I just tried to rollback and the compiler crashes now on a particular file (the assembler it looks like). So something changed on my system and it’s not working with older versions. No idea but it looks like I’m stuck with the slow version now. 😭

Regards,
Ryan Joseph

Sorry for all the noise. Did some tests and it looks like “uses” in the implementation section are what changed. When I start adding those in it re-compiles everything every time.

Were there known changes in that area since March 3rd 2023? Honestly they were causing so many crashes maybe they got pulled for incremental building. I’d rather take the crashes though then what I have now.

Regards,
Ryan Joseph

Hairy Pixels via fpc-pascal schrieb am
Mi., 4. Dez. 2024, 13:56:

Were there known changes in that area since March 3rd 2023? Honestly they were causing so many crashes maybe they got pulled for incremental building. I’d rather take the crashes though then what I have now.

The likely candidate is the reworked module loading that still has its problems.

@Michael: do you think you can take a look? I also got the feeling that it tries to compile more while nothing changed than with 3.2.2, though I did not yet have the time to nail this down more (or to compare it with the pre-task code).

Regards,
Sven

On Dec 4, 2024 at 8:13:08 PM, Sven Barth via fpc-pascal <

Indeed. Do you know what commit that was? I’d try rolling back again and seeing if I can figure out why that module is crashing the compiler. Maybe it’s fixable but I’m not sure.

I’ve tried to reproduce it but I haven’t found a way yet because there’s too many confounding factors and too much code.

Regards,
Ryan Joseph

Seems likely.

Yes, this is still on my todo list. The main problem is to have a really minimal example that demonstrates the issue. (and with minimal I mean something that doesn't require half the packages or lazarus to be recompled...)

Ryan, if you wish to help, please try to create the smallest possible example that demonstrates the issue.

Michael.

Michael Van Canneyt via fpc-pascal
schrieb am Mi., 4. Dez. 2024, 18:24:

I don't know if you consider it more minimal, but compiling the compiler seems to do the trick as well :P (though I haven't made sure whether it's really the same issue yet)

Regards,
Sven

Hairy Pixels via fpc-pascal schrieb am
Mi., 4. Dez. 2024, 14:24:

I don't have a specific commit right now, but essentially when the compiler/ctask.pas unit was added.

Regards,
Sven

Same here. With fpc-3.2.2 a full build is always necesssary, because of the internal errors that occur with partial builds. On the other hand, fpc-3.3.1 does a lot of (seemingly unnecessary) compiles.

Regards,

Adriaan van Os

Well, partially compiling the compiler has never worked for me, even before the change to task (I'm on linux 64bit).

So I'm inclined to think this is something different...

Michael.

Michael Van Canneyt via fpc-pascal
schrieb am Mi., 4. Dez. 2024, 21:52:

I do that regularly (crashes/internal errors mainly occur there if something in the interface section of some highly used unit changed). And I noticed quite a difference in compilation duration between 3.2.2 and 3.3.1 🤔

Regards,
Sven

On Dec 5, 2024 at 12:27:37 AM, Michael Van Canneyt via fpc-pascal <

Yes I tried already and failed but it’s on my TODO list now.

Regards,
Ryan Joseph

Hi,

Have you tried using the -vv command line argument and looking at the generated fpcdebug.txt? Maybe it gives some hints why the compiler decides to recompile certain units.

Charlie