> We could also place references to TLB files in TLB files themself, > and generate a TLB File per header file. In this case we could stop > parsing anything, it there is already a TLB file for an included > header. This could lead to big speedups, as we don't reparse all the > headers over and over again.
Before going into modifications on the typelib side, I would rather look into why it is so slow (and ask the clang mailing list how to make it faster). Compiling a file that includes base/Pose.hpp and does something with a base::Pose takes 1.61s on my machine, not 15s. Maybe there would be a way to prune the traversal at the declaration level since we really don't care about the inside of the methods. If we come to that, I would really really not break the self-contained nature of tlb files, because it won't be manageable (if you update a linked tlb file because a struct change but NOT the other ones, you are breaking the type definitions). What would definitely be doable is to save a self-contained TLB per header file in a cache folder and have the clang importer merge these tlbs into the current registry whenever an include is found. Now, how do you detect the includes without traversing the AST ? And -- more importantly -- how do you make sure that the cache is properly invalidated when some include-in-include-in-include file gets invalidated ? Or when the import options (such as the opaque list) gets modified ? Big can of worms. Sylvain _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
