Hi fpc devels,

I did some test with an integrated fpc (e.g. in an IDE) and sharing redirecting the file access. For example FPC could use the files of the IDE. This would allow to compile without saving to disk, so the compiler could be used for quick syntax checks and similar tasks. Note: Under Linux the speed up is hardly measurable. But maybe Windows can gain a bit.

I changed a few calls to Assign/Reset/Close to use the TCFileStream (e.g. for the ppu reader) and added the possibility to define a custom TCFileStream class. An IDE can then redirect the file access. I guess the maintenance cost is pretty low for you fpc devels.

Should I create a feature request with the patch or are there some other plans?

Mattias

Create a feature request with patch. I guess it is based on the exisiting compiler.pas interface?

I did some test with an integrated fpc (e.g. in an IDE) and sharing redirecting the file access. For example FPC could use the files of the IDE.

IMO most time can be saved by using the directory cache, instead of building another one in the compiler.

This would allow to compile without saving to disk, so the compiler could be used for quick syntax checks and similar tasks.

That's an old idea, still viable but never implemented.

Note: Under Linux the speed up is hardly measurable. But maybe Windows can gain a bit.

There's another issue with the .ppu files, that are used by the compiler to prevent excessive re-compilation of the same units. But recompilation can be forced, with some minor patching.

I changed a few calls to Assign/Reset/Close to use the TCFileStream (e.g. for the ppu reader) and added the possibility to define a custom TCFileStream class. An IDE can then redirect the file access.

The scanner already has a configurable file interface, but AFAIR only by global hooks, not on a per-file or per-application base (finput.pas: tdosinputfile...). No real problems, so far :-)

But there exist other issues, e.g. the compiler currently can compile only for a single target, that is incorporated at compile time. One solution were a dummy target, that does not create any binary code in the IDE compiler version. Or the compiler back-ends are moved into their own classes, 've explored both approaches
already :-)

DoDi

I only tested reading/writing files.
In a second step the functions for file existence, age and size can be made overloadable. I doubt it will make fpc faster under Linux, but I guess under Windows it could be noticeable in some cases.
The compiler spends some time parsing the ppu files. Maybe this could be cached, but as far as I can see this is not an easy task.

I'm not sure what issue you mean.

What global hooks do you mean?

I agree that a single exe multi platform compiler would be nice, but it is not necessary for my goal.
My goal is to reduce the overhead of invoking the compiler many times a day for the same project.

Mattias

ok. I will wait for DoDi's answer about the existing global hooks. Maybe the things I need are already there and I was just too blind to see them.

I guess it is based on the exisiting compiler.pas interface?

I used that for testing. I didn't change it.
In the next step I will play with TDirectoryCache.

Mattias

Ah, I thought you mean source files.

My tests on Windows show no noticeable impact of file handling. Even closing and reopening files frequently doesn't add significantly to the execution time - most probably due to the OS file cache.

When you want to use the compiler for syntax checks, a recompilation of the source code must be enforced. Otherwise the .ppu file is loaded, if exists, and no parsing checks for up-to-date .ppu files is not bullet proof, as can be seen with errors that go away or don't go away in a recompilation.

I didn't realize that you are talking about .ppu files, which IMO are of little use in the IDE.

What global hooks do you mean?

Dunno about the handling of .ppu files.

DoDi