[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