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.
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.
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.
DoDi
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
