[Lazarus] Some syntax changes

[Mattias Gaertner]

On Sun, 01 Aug 2010 04:12:29 +0200
Hans-Peter Diettrich <DrDiettrich1 at aol.com> wrote:

> Mattias Gärtner schrieb:
> 
> >> Make all compiler options objects (or records with IDs) in the IDE, 
> >> and let the (future) compiler handle them.
> > 
> > There is a difference between the stored options and the real options. 
> > Most options are stored as name, value pair. The real options are 
> > computed on demand. The compiler only needs the real options. The 
> > computed options are concatenated as command line string. Theoretically 
> > it can produce another output, but the compiler has everything to parse 
> > command line options, the speedup is not measurable. I think we should 
> > not add extra formats without need.
> 
> We should have kind of property editors for the options, so that the 
> user can pick valid values from a list - this is where the GUI may be 
> affected. Once the options are known by option descriptor and value 
> index, these values can be picked from and stored in the data structures 
> imported from the compiler. This would not necessarily make any speedup, 
> but could simplify the additional coding in the IDE.

What additional coding?

 
> > Let's first concentrate on what really takes time: file access.
> 
> WRT to the recent namespace discussion, IMO file access can be reduced 
> down to direct access of every (source) file. With project and package 
> files (does FPC already have packages?) the location of every used unit 
> should/could be known in advance, eliminating the need for an unit 
> search path at all. Make the output path stored in the project files as 
> well, and the location of the ppu/o files would be known as well.

I doubt that, because for backwards compatibility fpc has still to
search in the paths.

 
> All stored directory informations should allow for macros, so that e.g. 
> the target/machine specific directories can be exchanged, as is required 
> (currently) in building the compilers.
> 
> 
> >>> Although I guess they need different structures. But the
> >>> compiler could load files/directories from the IDE caches. That 
> >>> should speed up a lot, especially under windows.
> >>
> >> We only have to agree about a common base class...
> > 
> > Some kind of virtual file system is also needed for the version control 
> > addons.
> 
> On newer (64 bit) systems memory mapped files can be used, so that every 
> file has to be mapped only once and, thanks to the huge address space, 
> can stay mapped until the IDE is closed. This would eliminate all file 
> searches in the integrated compiler. Some re-mapping may be required 
> when extending source files while editing, but this could be reduced by 
> sufficiently large file mappings for all such files. Eventually unused 
> parts are eliminated by the OS RAM paging.

Correct me if I'm wrong: memory mapped files is a more direct access to
the OS file cache. You can omit the copy on loading and the copy-back
on writing. 
The IDE loads/saves files as whole with one TFileStream.Read/Write
call.

I tried to measure the time of the copy: 
The code browser loads under Linux fpc 2.5.1 about 87 MB of sources
and takes on this machine about 4.5 seconds.
I doubled the copy on load and it is still about 4.5 seconds.
I put the copy on load in a loop for 10 times and it is still about 4.5
seconds.
That's why I doubt that memory mapped files will give a noticeable speed
increase.


Mattias