Front End Performance: Migrate ZObject internal representation from flat table to nested object
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	gengh
	Jun 9 2025, 2:35 PM

Description

The ZObject represented on the page is stored in the zobject.js store module as a flat table, where every node (and hence, every child ZObject represented under that node) can be reached directly by any component using its unique row id.

More details about this: https://www.mediawiki.org/wiki/Extension:WikiLambda/Frontend_Architecture#ZObject_Table

While this data structure is beneficial for direct node value access, it is not scalable with large objects.

More details about performance issue: https://docs.google.com/document/d/1q-AkqLXx0jT43eLj1IxBqE6XpjHRqFdeiwNh4buaAzQ/edit?tab=t.0

We have tried a number of mitigation strategies and the performance improvements are minimal. We've determined it is high priority to move away from flat table representation and into nested object, using Pinia store reference features.

The following POC has shown this possibility performs well, loads immediately and doesn't require an excessive refactor:
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiLambda/+/1126604

Desired behavior/Acceptance criteria

ZObject is stored as is (converted to hybrid form) instead of flat table
Front-end load times visibly improve
UI can load an expanded Q144 wikidata object in a reasonable time with no browser crashes
Unit test coverage is equivalent to current
UI snapshots are identical
Integration and e2e tests pass with no changes
Frontend Architecture documentation is updated

Completion checklist

Before closing this task, review one by one the checklist available here: https://www.mediawiki.org/wiki/Abstract_Wikipedia_team/Definition_of_Done#Front-end_Task/Bug_Completion_Checklist

Details

	Subject	Repo	Branch	Lines +/-
	Migrate ZObject internal representation from flat table to nested object	mediawiki/extensions/WikiLambda	master	+15 K -18 K

Customize query in gerrit

Related Objects
Search...

Status	Assigned	Task
Resolved	Jdforrester-WMF	T390546 Extend features to use Wikidata items more fluently, so that Wikifunctions editors can do more things and so address content gaps more readily.
Resolved	gengh	T390560 Improve the performance in the Wikifunctions front-end, so that function creators and users can use complex and large Objects such as those from Wikidata without difficulty
Resolved	gengh	T396360 Front End Performance: Migrate ZObject internal representation from flat table to nested object

Event Timeline

gengh created this task.Jun 9 2025, 2:35 PM

gengh changed the task status from Open to In Progress.

gengh claimed this task.

gengh added a parent task: T390560: Improve the performance in the Wikifunctions front-end, so that function creators and users can use complex and large Objects such as those from Wikidata without difficulty.

gengh moved this task from To Triage to 25Q4 (Apr–Jun) on the Abstract Wikipedia team board.

gengh edited projects, added Abstract Wikipedia team (25Q4 (Apr–Jun)); removed Abstract Wikipedia team.

gengh moved this task from Incoming to In Engineering on the Abstract Wikipedia team (25Q4 (Apr–Jun)) board.

gengh mentioned this in T390560: Improve the performance in the Wikifunctions front-end, so that function creators and users can use complex and large Objects such as those from Wikidata without difficulty.Jun 9 2025, 2:46 PM

Change #1126604 had a related patch set uploaded (by Genoveva Galarza; author: Genoveva Galarza):

[mediawiki/extensions/WikiLambda@master] [WIP] Migrate ZObject internal representation from flat table to nested object

https://gerrit.wikimedia.org/r/1126604

gerritbot added a project: Patch-For-Review.Jun 9 2025, 3:14 PM

DSantamaria triaged this task as High priority.Jun 9 2025, 4:12 PM

DSantamaria added a project: OKR-Work.

gengh moved this task from In Engineering to In Code review on the Abstract Wikipedia team (25Q4 (Apr–Jun)) board.Tue, Jul 1, 12:37 PM

gengh mentioned this in T391136: [Stretch] Namespace ZObject tables to remove the extra complexity of deleting Detached objects.

Observed improvements on
table 1: Load time
table 2: Browser memory

Name	V1 (ms)	V2 (ms)	Load time improvement ratio
Edit Z19940	300	300	1.00×
Edit Z1234	317	300	1.06×
Edit Z8	6823	2415	2.83×
Edit Z4	11650	3307	3.52×
Edit Z866	30270	1204	25.14×
View Z19940	309	300	1.03×
View Z1234	251	300	0.84×
View Z8	3379	682	4.95×
View Z4	8319	832	10.00×
View Z866	3954	247	16.01×
Z6821(Q818363) First request	318	69	4.61×
Z6821(Q818363) Subsequent request	5148	78	66.00×
Z6821(Q818363) Expand response (all item lists)	13432	1437	9.35×
Z6821(Q144) First request	909	127	7.16×
Z6821(Q144) Subsequent request	129126	116	1,113.16×
Z6821(Q144) Expand response (all item lists)	∞	6130	∞

Name	V1 (MB)	V2 (MB)	Browser memory improvement %
Edit Z19940	59	57	3.39%
Edit Z1234	56	62	-10.71%
Edit Z8	265	158	40.38%
Edit Z4	430	202	53.02%
Edit Z866	227	105	53.74%
View Z19940	58	53	8.62%
View Z1234	53	57	-7.55%
View Z8	157	73	53.50%
View Z4	240	85	64.58%
View Z866	70	55	21.43%
Z6821(Q818363) First request	94	61	35.11%
Z6821(Q818363) Subsequent request	106	64	39.62%
Z6821(Q818363) Expand response (all item lists)	535	143	73.27%
Z6821(Q144) First request	117	63	46.15%
Z6821(Q144) Subsequent request	114	66	42.11%
Z6821(Q144) Expand response (all item lists)	5000	488	90.24%