NEW 173242
[WebIDL] New model for aggregate generation of WebIDL bindings
https://bugs.webkit.org/show_bug.cgi?id=173242
Summary [WebIDL] New model for aggregate generation of WebIDL bindings
Sam Weinig
Reported 2017-06-11 12:22:45 PDT
The bindings have been getting much better lately, but we are running into a wall, performance wise, due to the need to gather information about interfaces/dictionaries/enums other than the one currently being generated. I would like to propose a new model, that should allow us to parse each IDL file at most once (or in a simplified form, at most twice). The basic idea is to formalize our current split processing (preprocess-idls.pl and generate-bindings.pl) into two phases, parsing and code generation, with a data structure, the 'type database' being used to bridge the gap between them. - In the parsing phase, we parse each IDL file and build up a 'type database' (essentially a big map of all the IDL types and their characteristics, parent type, exposure and compatibility aliases, inheritable extended attributes, named/indexed getters/setters, serializers, etc.) by extracting relevent information. Then, we dump the parsed form to a file so it can be reconstructed quickly, without re-parsing, using Storable (this is the optional step, we can always just do a second parse for code generation). - In the code generation phase, we take as input, an IDL file (or it's parsed form mapped in from disk) and the 'type database'. As a rule, all code generation should be possible with only those two input. If additional information is needed, it should be extracted during the parsing phase, and added to the 'type database'. (This leaves out partial interfaces and implements statements. We will probably want to do something like have them participate in the parsing phase just like any other IDL file, and then during code generation, we do a merge before the real generation has begun). Thoughts?
Attachments
Chris Dumez
Comment 1 2018-09-04 09:20:51 PDT
Sounds good to me.
Yusuke Suzuki
Comment 2 2018-09-06 06:34:38 PDT
Sounds super nice!
Darin Adler
Comment 3 2018-09-08 13:59:04 PDT
I don’t understand the lifetime of the type database file. Is it something that is left behind from one compilation and used for the next? Is it a global shared file?
Sam Weinig
Comment 4 2018-09-09 15:30:23 PDT
(In reply to Darin Adler from comment #3) > I don’t understand the lifetime of the type database file. Is it something > that is left behind from one compilation and used for the next? Is it a > global shared file? I have to admit I don't entirely remember what I was thinking, as I filed this about 15 months ago, but I am pretty sure the idea was that it would be left over from one compilation to the next.
Note You need to log in before you can comment on or make changes to this bug.