Wikifunctions:Status updates/2024-08-23

◀

Wikifunctions Status updates

▶

This quarter, the Abstract Wikipedia team committed to improve system performance. We performed a bottleneck analysis of function calls, tracking how much time the system spent making HTTP requests, performing calculations, and managing resources. We found that the single slowest operation–by far!–was starting up the WasmEdge CLI.

We've talked about WasmEdge before: briefly, it's is a system interface for WebAssembly (WASM). It allows WASM code to interact with the operating system. We mostly use it so that our code executors can read/write standard streams and be guaranteed to touch nothing else – no files, no network access, and no other processes – which is a key part of our work to ensure the integrity and security of the services. Unfortunately, it turns out that WasmEdge takes around 300 ms to spin up in our production environment before it's ready to handle any data.

The solution we devised for this issue is to keep several WasmEdge processes running at all times. That way, when a request is made, the evaluator doesn't have to wait for a new process to get ready: instead, it can simply pick a ready one from the pool and run your request immediately.

We deployed these changes on Wednesday, and, as has been already noticed by many of you, Wikifunctions has become considerably snappier. Congratulations to the team for getting this deployed!

As mentioned above, the biggest thing we shipped this week was a large re-write of how the back-end "evaluator" service works, which we hope will have a significant improvement on perceived performance. This is one of the big pieces of work we committed to this Quarter. Instead of loading WASM on request, we're now pre-loading it into a pool of ready threads (T371837). From some initial testing, calls seem roughly 3–12x faster for single requests (depending), and 30% faster for saturated requests, but we're interested in how well it works for you in practice!

We also made some front-end improvements. When editing Function labels, we now show and enforce the length limit on the front-end (T370995) for new labels. If you’ve previously created a label that’s longer than the new limits, we encourage you to shorten it within the new limit. We’ll give everyone some time and help to do this, and we’ll aim to enforce the limit once all the labels are ready. More details will come up in future updates. We also fixed a bug that meant that on Function pages the checkboxes in the tables for Implementations and Test cases were wrongly aligned.

We fixed a bug that meant we would create meta-data objects with a key and no information in some circumstances (T369625). We re-wrote our code so that we share the logic to change the page's displayed title when you alter the label between the Function editor and the "About dialog" editor, to be consistent and avoid the chance for bugs (T371350).

We worked on some API and general code improvements, to share code more consistently and reliably, which allowed us to add a feature flag for the 'repo' nature of the WikiLambda code. This means that in future we'll be able to install the extension on other wikis in 'client' mode, as part of the work to let you embed calls to Wikifunctions inside articles, using wikitext.

As part of our "Fix-It" technical debt work two weeks ago, we landed a few further improvements. The biggest one was a comprehensive re-write of our front-end styling code to use consistent naming conventions (documented on MediaWiki.org), which helped us find a number of now-unused code and one hard-coded i18n label (T369596). We added some testing of the Wikifunctions UX application's browser history editing, as this is a tricky and confusing area to break. We also tweaked a couple of i18n labels to demonstrate to translators where to place the {{PLURAL:$1|$1 …|$1 …}} syntax.

Meeting so many multi-lingual users from our community at Wikimania, I came back inspired to think deeper on this topic.

Despite having spent several years learning and actively coding, I hadn’t fully wrapped my head around the subtle yet crucial role that language ability plays in being a coder who writes quality code. If you are proficient in English, the out-of-the-box functions of popular coding languages make more sense to you than otherwise, you will be naturally better at naming your own functions, you comment better, I can go on. What drives our team to improve Wikifunctions every day is the revolutionary idea of allowing users to write code in their own language. This approach moves us beyond the concept of a single dominant language, creating a level playing field that empowers users to write in their own way. Excellent functions have very little to do with the natural language of their labels, and yet, so much to do with building our diverse community of users. We encourage you to write in your native language.

Speaking of labels, if you're new to Wikifunctions and not yet comfortable with writing functions, a great way to contribute to our vibrant community is by translating function labels and descriptions into your language. You can also suggest a function to be created in your language.

In the past few weeks, I’ve selected functions that are radically different, showcasing the diversity of our function library, even in its early stages. Continuing this theme, this week I have chosen a blood compatibility tool. This Function checks whether two blood groups are compatible, helping to determine if blood donation or receipt is possible.

The Function takes two String inputs for the blood types we want to compare and outputs their compatibility in the form of a Boolean. For instance, if you input ‘A’ and ‘B’ as the types you are interested to know the compatibility of, a result of ‘true’ infers they are compatible and ‘false’ if they are not. Maybe in future the Function can be changed to use a custom Type to represent blood type, but this works well enough for now.

The Function currently has one Implementation in Python which accepts two blood types as input , converts them to uppercase, and checks if they are valid blood types. It then checks if the pair of blood types (either in the order provided or reversed) is present in the pre-defined plasma_table, which lists compatible plasma donation pairs. If the pair is found in the table, the function returns True, indicating compatibility; otherwise, it returns False. If either of the blood types is invalid, it returns None.

It currently has two Tests that demonstrate what to expect from the function. One for a compatible type and another for non-compatibility. We encourage you to add more implementations and edge case handling to improve this function.