<feed xmlns='http://www.w3.org/2005/Atom'>
<title>pure/research/experiments/030-app-lifecycle/items-next.aup, branch master</title>
<subtitle>Verified execution runtime unifying state, persistence, and replication.
</subtitle>
<id>http://git.yeowoo.org/pure/atom?h=master</id>
<link rel='self' href='http://git.yeowoo.org/pure/atom?h=master'/>
<link rel='alternate' type='text/html' href='http://git.yeowoo.org/pure/'/>
<updated>2026-10-04T09:31:09Z</updated>
<entry>
<title>Measure how long an app changing module cannot answer, against a host restart (030)</title>
<updated>2026-10-04T09:31:09Z</updated>
<author>
<name>eunhhu</name>
<email>necpition205@gmail.com</email>
</author>
<published>2026-10-04T09:31:09Z</published>
<link rel='alternate' type='text/html' href='http://git.yeowoo.org/pure/commit/?id=93261d1c157e50f1ed2bbc14cf68f2822553b69c'/>
<id>urn:sha1:93261d1c157e50f1ed2bbc14cf68f2822553b69c</id>
<content type='text'>
An app of a million items (a list grown by doubling) or of a thousand, in
a host of apps, its store in RAM: the longest gap between two answered
writes while it changes module on SIGHUP (stopped and started again from
its store, 71e319b), and while the host is restarted. A thousand items:
1.59 ms against 3.05 (median of 20 and 10). A million: 150.64 ms against
149.73 (10 and 5): both are the store read again (pure_app_start, 142
ms), so changing does not answer sooner than restarting.
</content>
</entry>
</feed>
