Type-Aware Optimizations with Imperfect Types
Bibliographic record
Abstract
JavaScript, a programming language originally designed for web browsers, has become ubiquitous, experiencing adoption across multiple platforms. Its dynamic type system and prototype-based object orientation are well-known properties that make the language applicable to several programming paradigms, particularly functional and object-oriented programming. However, issues such as global scope pollution, implicit type conversion, the absence of native null safety features, and the complexities of asynchronous callback structures, among others, make the language difficult to work with. To address these challenges, particularly within the context of large-scale application development, TypeScript was introduced. \n \nTypeScript incorporates a structural type system and compiles to JavaScript. The design objective is to ensure seamless interoperability with JavaScript, incorporating various ergonomic features, notably static typing. TypeScript introduces improved tooling, IDE support, ES6 features with extensions, and compatibility with existing JavaScript code. Despite these advantages, TypeScript deliberately refrains from optimizing its JavaScript output. Although JavaScript’s flexibility can often be useful in practice, a naive implementation of the language would be slow. Modern JavaScript engine implementations are intricate systems that employ cutting-edge optimization techniques to achieve efficient executions. \n \nThis thesis introduces a method for improving the runtime performance of JavaScript by utilizing type information from TypeScript. It categorizes TypeScript types based on usage into two groups: nominal (similar to classes in Java) and non-nominal (structural or arbitrary). Although TypeScript’s type system is inherently unsound, types tend to be consistent in most nominal use cases. This characteristic renders a significant proportion of type information amenable to optimization with reasonable guarantees. \n \nI modified the TypeScript compiler (tsc) to leverage nominal type usage for optimizations. This modification produces optimized code through the utilization of enhanced heuristics for runtime optimizations. Additionally, I integrated WebKit’s JavaScript engine, JavaScriptCore (JSC), by introducing a new runtime intrinsic specifically designed to utilize type information from TypeScript. \n \nPerformance is assessed by comparing JavaScript programs from the JetStream 2.1 JavaScript test suite with equivalent programs ported to TypeScript. These TypeScript programs are then compiled to JavaScript using the modified TypeScript compiler in two modes: with optimizations enabled and with optimizations disabled. The results show that adopting a nominal typing style in TypeScript leads to improved performance in the resulting JavaScript when compiled with optimizations enabled, by up to 12%.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.002 | 0.010 |
| Meta-epidemiology (narrow) | 0.001 | 0.001 |
| Meta-epidemiology (broad) | 0.001 | 0.002 |
| Bibliometrics | 0.001 | 0.002 |
| Science and technology studies | 0.001 | 0.002 |
| Scholarly communication | 0.003 | 0.005 |
| Open science | 0.002 | 0.003 |
| Research integrity | 0.001 | 0.002 |
| Insufficient payload (model declined to judge) | 0.009 | 0.003 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".