On Wed, 29 Sep 2010 22:50:47 +0200 Hans-Peter Diettrich <drdiettri...@aol.com> wrote:
> Mattias Gaertner schrieb: > > > 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. 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. > > 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'm not sure what issue you mean. > > 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 :-) What global hooks do you mean? > 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, selectable at runtime. I've explored both approaches > already :-) 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 _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
