#### Description
This is a request for a performance review of the [[ https://gerrit.wikimedia.org/r/admin/repos/mediawiki/extensions/WikiLambda | WikiLambda MediaWiki extension ]]. The initial implementation of the extension will allow users to use JSON syntax (via a JS UI or raw entry) to invoke extension-defined functions with extension-supported types, and support composition of those functions and types. At present, the functions run in the PHP runtime. (Eventually users will be able to write functions in programming languages like JavaScript, but a Q2 FY 2020-2021 implementation ma not support this capability, as we're in the early stages.)
WikiLambda is a component of the computing infrastructure for The [[ https://meta.wikimedia.org/wiki/Abstract_Wikipedia | Abstract Wikipedia ]] initiative, which is targeted at community authored natural language generation routines. For the background on the general architecture concept, refer to https://arxiv.org/pdf/2004.04733.pdf.
#### Preview environment
This component has not been deployed to the beta cluster. We will need to plan that. However, this task is being filed in anticipation of Q2 FY 2020-2021 to ensure a slot for performance testing.
It is presently possible to run WikiLambda in [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/master/DEVELOPERS.md | MediaWiki-Docker ]] with minimal configuration (Vector + the extension are all that are needed). For those reading this task at its initial submission, we're presently discussing if and how to add CirrusSearch capabilities within Docker to aid in the frontend UX for function / type / label / signature lookup.
#### Which code to review
We'll be particularly interested in the performance characteristics of the server-executed code. It should be noted that we expect this new Wikimedia project's user base to be small at first, and therefore its computational needs comparatively modest at first.
Performance evaluation of the JavaScript- and HTMLForm-based frontend UX would also be appreciated, but we're flexible on this if needed.
#### Performance assessment
Q&A:
- What work has been done to ensure the best possible performance of the feature? So far, we haven't begun optimization for performance.
- What are likely to be the weak areas (e.g. bottlenecks) of the code in terms of performance? Type conformance checking on the JSON UGC is a known potential soft spot - functions and types nested within functions and types can become combinatorially challenging, but more importantly, having a means of type checking fast without excess database queries is likely needed. By the time of the performance assessment we may have some approach, although we're naturally interested to discuss the approach before actual implementation if at all possible.
- Are there potential optimisations that haven't been performed yet? Yes, on the type conformance checking. It's a little early, but we may also be interested by the time of the review in ways to ensure that the on-wiki defined test suites can run as efficiently as possible.
- Please list which performance measurements are in place for the feature and/or what you've measured ad-hoc so far. If you are unsure what to measure, ask the Performance Team for advice: [[ mailto:performance-team@wikimedia.org | performance-team@wikimedia.org ]]. Nothing yet. We do intend to have various profiling measures in place, as it will likely play into different types of optimization (e.g., whether to run a function in our system-defined PHP sandbox versus executing in a Node runtime if a JavaScript UDF is also available for a function) and we'll need guards in place to monitor and address yet-to-be-defined SLOs.