On Sun, 01 Aug 2010 04:12:29 +0200 Hans-Peter Diettrich <[email protected]> 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 -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
