Update README.md

README.md

@@ -115,20 +115,13 @@ The solution of explicit compile hints addresses the identified use cases by pro
 
 ## Detailed design discussion
 
-### [Tricky design choice #1]
+### Per-file or per-function?
 
-[Talk through the tradeoffs in coming to the specific design point you want to make.]
+If compile hints apply to the full file, web developers can manually select a "core file" of their web page for eager compilation. Selecting individual functions for eager compilation would need to be done in an automatic fashion - modern pages have tens of thousands of JavaScript functions, and improving the page load time requires selecting thoudands of them for eager compilation.
 
-```js
-// Illustrated with example code.
-```
-
-[This may be an open question,
-in which case you should link to any active discussion threads.]
-
-### [Tricky design choice 2]
+Selecting a whole file for eager compilation might overshoot: if some functions are not needed, compiling them takes CPU time, and storing the compiled code takes up memory (although, unused code can eventually be garbage collected).
 
-[etc.]
+In this proposal, we're proposing a magic comment for marking the whole file for eager compilation. We'd like to make it easy to extend the feature to be able to mark individual functions in the future.
 
 ## Considered alternatives
 
@@ -141,7 +134,7 @@ Example:
 
 The payload would describe the function positions of the functions to be eagerly compiled. Designing a suitable payload format is non-trivial.
 
-We'd also need to make sure that web development toolchains can generate the per-function data and incorporate it in an automatic fashion. Here, we suggest a profile-guided optimization (PGO) approach: first running the web page and logging which functions were called, and generating the per-function annotation based on the data. This area needs more experimentation.
+We'd also need to make sure that web development toolchains can generate the per-function data and incorporate it in an automatic fashion. For finding the functions, we suggest a profile-guided optimization (PGO) approach: first running the web page and logging which functions were called, and generating the per-function annotation based on the data. This area needs more experimentation.
 
 We'd like to keep this alternative as a future extension, and propose the per-file magic comment solution first.
 
@@ -167,7 +160,7 @@ class C {
 }
 ```
 
-The top-level "use eager" directive is very similar to the top level magic comment we're proposing. The downside is that the per-function "use eager" directive would bloat the source code size. This is unoptimal; although compression would alleviate the tramitted file size overhead, parsing the magic comments still adds overhead which we think is unnecessary.
+The top-level "use eager" directive is very similar to the top level magic comment we're proposing. The downside is that the per-function "use eager" directive would bloat the source code size. This is unoptimal; although compression would alleviate the transmitted file size overhead, parsing the magic comments still adds processing overhead which we think is unnecessary.
 
 In addition, the per-function compile hint data should be automatically generated by the web development toolchains, so it's unnecessary to have it in the source code next to the function. We don't expect humans to look at or edit the data when working with the source code.