[CC to dypgen for interest, skip if not interested :]

I have just reduced the binding time for the Felix standard library
from around 230 seconds to 23 seconds by the simple expedient
of only parsing the syntax once per run of flxg (the Felix compiler).

The automaton is still built once per file.

In principle I can reduce this time further by saving the result of the
parse which is contained in the "local_data" value returned.
And I can speed it up again by adding the Marshalled value
of the automaton to local_data as a string, and completely avoid
parsing the syntax (except once).

However I'm thinking this is a bit of a pain because it creates yet
another "cache" file which requires version checking etc to see
if it is up-to-date.

An alternative is to add this data to the cache of the standard library.

However this raises an interesting issue! At present the standard library
code can contain syntax definitions. But it gets lost at the end of the file
library build....

... but it won't if I save the local data from the parse from AFTER the library
build, and make sure I pipeline local data through the build (instead of
parsing each file with a fresh initial local data).

In fact since local data also contains the parse tree, we probably don't
want to do exactly that (since the parse trees and aggregated and bound
and aren't required after that). In fact, we want to retain the statements
from the initial --import files because they contain global macros
(primarily MACOSX, LINUX, etc  which identify the current platform).

But the POINT is that with a bit of fiddling, it become feasible to add
syntax to the library where it is needed. For example if you have a 
library module implementing lattice data structure you might want to 
add VEE and WEDGE operators.

--
john skaller
skal...@users.sourceforge.net





------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to