LifeViewer load times

[confocaloid]

Edit by Sokwe: this is a thread about LifeViewer load times.

EDIT by dvgrn: LifeViewer can handle this okay:

Technically it fits in LifeViewer, but it is still too large to be conveniently viewable in LifeViewer (a reader who would like to see the pattern working or to study how ot works would most likely need to load it into Golly). Further, when there are multiple such very big RLEs on a page, that causes noticeable lag (noticeably slows down page load time). I think "attachment instead of plain RLE" remains a better choice until the pattern is small enough to actually run it in LifeViewer and see details. See viewtopic.php?p=202803#p202803 viewtopic.php?p=202833#p202833 for a related discussion.

[dvgrn]

... when there are multiple such very big RLEs on a page, that causes noticeable lag (noticeably slows down page load time).

This page of this thread currently loads for me in about one second, and the puffer runs in LifeViewer plenty fast enough for me to see at a glance how it works -- it gets through a full cycle in about four seconds, and that shows everything that's really there to be seen. But I'm not using a phone or a slower Internet connection, so my experience might not match the average user's.

Can anyone else who is seeing significant lag please report how many seconds it is taking this page to load? I'll eventually move this whole discussion over to the "miscellaneous posts" thread that confocaloid linked to -- but for the time being, this page is where a load-time test can be conveniently run.

I'm happy to trade a few seconds of lag for a LifeViewer view of one of these spaceships, and RLE that I can copy directly out and into Golly, instead of going through the extra download/open/copy steps required by an attachment. But if I'm causing problems for a large fraction of the user base, I'm happy to adjust to a different default way of presenting medium-sized patterns like the one above.

[confocaloid]

For the record: for me, it currently takes approximately ten (10) seconds for all the viewers to "initialise" (for the show-in-viewer links to appear). After that, when I click on the show-in-viewer link for the puffer, it takes approximately five (5) seconds before the viewer window opens. After that, when I try to run the puffer, it runs slowly and needs about 1 minute for a cycle.

To be able to see the interesting details or investigate how it works, I will need to load it into Golly anyway.
I'm not using "a phone or a slower Internet connection" either.

[Aleph]

Would it be possible to have a "LifeViewerable attachment"?
This would make it possible for LifeViewer to initialize as needed, instead of always initializing. This way, slow devices or slow internet connections won't be affected unless LifeViewer is actually initialized.
EDIT: Another name I kind of like for this idea is "lazy LifeViewer"; it isn't initialized until it's needed, just like how lazy evaluation doesn't evaluate until needed.

[rowett]

Some notes on LifeViewer performance:

1) If you're on a desktop machine you can see the page scan time from the browser console. For example this is the output from my machine from the previous page using Chrome:

Code: Select all

lv-plugin.js:1580 LifeViewer
lv-plugin.js:1250 refresh rate 60Hz
lv-plugin.js:64 read popup: 2.308837890625 ms
lv-plugin.js:64 read popup: 2.1640625 ms
lv-plugin.js:64 read popup: 1.867919921875 ms
lv-plugin.js:64 read popup: 1.321044921875 ms
lv-plugin.js:64 read popup: 0.2080078125 ms
lv-plugin.js:64 read popup: 0.3330078125 ms
lv-plugin.js:64 read popup: 0.171142578125 ms
lv-plugin.js:64 read popup: 1.216796875 ms
lv-plugin.js:64 read popup: 36.48095703125 ms
lv-plugin.js:64 read popup: 0.2060546875 ms
lv-plugin.js:64 read popup: 40.071044921875 ms
lv-plugin.js:64 read popup: 32.761962890625 ms
lv-plugin.js:64 read popup: 1.44091796875 ms
lv-plugin.js:64 read popup: 23.4580078125 ms
lv-plugin.js:65 page scan: 150.52001953125 ms

This says that there were 14 posts containing RLE (read popup), the largest of which took 40ms on my machine to decode. The page scan in total (from when the page loads, to when the SHOW IN VIEWER links appear) took 150ms.

2) Although not released yet, when running the pattern LifeViewer Pro is over twice as quick. On my machine it takes 5.4 seconds to iterate over the first 1000 generations (185gps). LifeView Standard takes 11.4 seconds (87 gps).

3) I'll take a look at pattern loading and see if there are any optimizations to be had.

[rowett]

3) I'll take a look at pattern loading and see if there are any optimizations to be had.

Build 1231 much improves the read popup and page scan times. The previous page now takes 47ms to scan on my machine (vs 150ms before).
Additionally, code boxes containing valid patterns will be reduced in height to use less real estate on the page.

[dvgrn]

Would it be possible to have a "LifeViewerable attachment"?
This would make it possible for LifeViewer to initialize as needed, instead of always initializing. This way, slow devices or slow internet connections won't be affected unless LifeViewer is actually initialized.

I won't try to speak for rowett on this -- it's always possible that some dark magic of this sort could be arranged. It looks awkward enough to me that I'd guess that it's not a likely feature to be implemented, but I am frequently wrong about such things.

Another option is putting larger pattern files somewhere else entirely. In this case, the .mc files that FWKnightship has been attaching are a quarter of a megabyte, but in RLE format the patterns are down under 160K now. There's a water strider article with the most recent pattern in the Infobox; does clicking on that link count as "lazy LifeViewer initialization"?

... Of course that potentially gets us back to a different tricky balancing act, which is the question of whether to update RLE:waterstrider every time a small optimization is made, or only sometimes, or never update it and somehow keep a record of every incremental improvement in a table or somewhere. But let's cross that bridge when we come to it!

[confocaloid]

31c/240 spaceship, 62887 cells:

Code: Select all

x = 16023, y = 14960, rule = B3/S23

I remember daydreaming about a 31c/240 spaceship being able to be viewed in Lifeviewer, it seems it came true. [...]

Please don't duplicate a large pattern in a quote like this. Instead of quoting the entire long RLE, it is better to trim it and quote only the RLE header (as I did in my quote). People who would like to see the pattern will be able to go back to the post.

[...] There's a water strider article with the most recent pattern in the Infobox; does clicking on that link count as "lazy LifeViewer initialization"? [...]

For LifeWiki readers (many of which aren't forum members), putting a large pattern in a LifeViewer in the infobox still can significantly slow down the browser. Further, it no longer displays enough visible details to the reader in the infobox window. I think for large patterns like this, it is better to show a static image in the infobox, rather than a LifeViewer embed. Related discussion: viewtopic.php?p=203009#p203009

[dvgrn]

For LifeWiki readers (many of which aren't forum members), putting a large pattern in a LifeViewer in the infobox still can significantly slow down the browser.

Similar to the case with forum pages, different people's experiences seem to be very different on this point.

For me the "water strider" LifeWiki article loads in less than a second -- not surprising, since the RLE is only 159K. And I find it very useful to be able to click on the pattern in the article Infobox, have a quick look at it, maybe zoom in and run it to look at details -- and then Ctrl+C copy the pattern out to quickly bring into Golly. So in this particular case I don't want a static image in the infobox; I wouldn't be able to do any of those things.

@confocaloid, what is your experience with loading that article page, especially now that Chris Rowett has done some LifeViewer optimization? Does it still rise to the level of a significant slowdown?

A couple of people have spoken up now to say that an immediate LifeViewer view of patterns of this size is convenient enough to be highly preferable, even at the cost of a small increase in load time. Nobody else has yet mentioned having any noticeable problem with load times.

[confocaloid]

For LifeWiki readers (many of which aren't forum members), putting a large pattern in a LifeViewer in the infobox still can significantly slow down the browser.

@confocaloid, what is your experience with loading that article page, especially now that Chris Rowett has done some LifeViewer optimization? Does it still rise to the level of a significant slowdown?

Opening the page Water strider freezes the browser for about 10-15 seconds, before the visible pattern even appears.
When the pattern finally appears, the infobox width visibly changes ("jumps").
Then, if I click on the infobox viewer, the browser freezes again for about 10-15 seconds.

I think I would describe that as significant slowdown. Neither my device nor my connection is the worst possible case, as far as can be expected from LifeWiki readers.

In many cases (including this one), "just because you can doesn't mean you should". (E.g. people can invent names for patterns they found, but that doesn't mean every pattern needs a name.)
Being able to put a pattern into a LifeViewer embed doesn't mean it should be put into LifeViewer embed. These patterns are still large, from the viewpoint of a LifeWiki reader, even if they might be considered "small" from the viewpoint of someone who has experience building patterns that a LifeWiki reader might describe as "tremendously large".

[rowett]

Opening the page Water strider freezes the browser for about 10-15 seconds, before the visible pattern even appears.
When the pattern finally appears, the infobox width visibly changes ("jumps").
Then, if I click on the infobox viewer, the browser freezes again for about 10-15 seconds.

Would you mind letting me know the specifics of your device? It will help with further optimization planning.

[confocaloid]

Would you mind letting me know the specifics of your device? It will help with further optimization planning.

Firefox 134, otherwise the same device as previously:

Celeron 4205U, 4GB RAM, Ubuntu 22.04,

[...] Laptop, Ubuntu 22.04 / GNOME 42.9, resolution 1366x768, [...]

[dvgrn]

Opening the page Water strider freezes the browser for about 10-15 seconds, before the visible pattern even appears.
When the pattern finally appears, the infobox width visibly changes ("jumps").
Then, if I click on the infobox viewer, the browser freezes again for about 10-15 seconds.

I think I would describe that as significant slowdown.

Interesting! Yup, that's definitely a significant slowdown.

I'm curious as to why it's taking so extraordinarily much time on your system. Both of the situations where you're seeing your 10-15 second lags take well under a second on every computer I've tried -- and I have nothing close to the best Internet or CPU speed. I'm still wondering if anyone else is seeing similar 10-15 second lags.

The RLE size really shouldn't be an issue here -- I've triple-checked it, and it really is only 159KB. For comparison, even a moderate sized image can easily be three times that.

You don't see anything like a 10-15 second delay when you load this sample image, do you? This is 392K, over twice the size of that RLE.



Assuming you're not routinely waiting 10-15 seconds to download small images like this ... it seems like the problem might be something more subtle.

Might it have something to do with how long it takes your system to access LifeViewer, or for LifeViewer to access RLE files on conwaylife.com in general? What kinds of load times are you seeing for smaller RLEs, like say Unsynthesizable oscillator 1?

[confocaloid]

Static images load and show very quickly, less than a second. The problem is in the time it takes for the LifeViewer embed(s) to initialise, and then the time before showing a LifeViewer window when clicked.
Unsynthesizable oscillator 1 initialises in ~1-2 seconds, and takes about 1 second to show when the infobox viewer is clicked.

[Sokwe]

I have moved this discussion to a new thread in the LifeWiki Discussion forum, as it was off-topic in the 31c/240 caterpillar thread.

Unsynthesizable oscillator 1 initialises in ~1-2 seconds, and takes about 1 second to show when the infobox viewer is clicked.

That seems like a long time for that pattern. I imagine that pages with lots of viewers, like the various hassler pages or Lifeline issues, would load abysmally slowly. I had certainly noticed this when testing the layout of the Lifeline pages on my phone a few years back. I want the wiki to be accessible, and 10+ second page load times seem like they are a problem that should be dealt with.

Would it be possible to have a "LifeViewerable attachment"?
This would make it possible for LifeViewer to initialize as needed, instead of always initializing. This way, slow devices or slow internet connections won't be affected unless LifeViewer is actually initialized.

This might be too much work to implement or it might not meaningfully improve performance, but I wonder if it would be possible to have a LifeViewer option for thumbnails that only draws the pattern in generation 0 using the selected theme colors without loading up any of the rest of LifeViewer (so no animations, no annotations, and no evolving the pattern). The thumbnail could then still be clicked on to load the full LifeViewer.

Another option might be to somehow give the ability to create links on the wiki that, rather than go to another page, instead open the LifeViewer with the specified pattern. Then we could presumably have an ordinary static .png image in the infobox that would open the pattern in LifeViewer when clicked on. However, I'm not sure how easy this is to get working with MediaWiki.

[confocaloid]

Unsynthesizable oscillator 1 initialises in ~1-2 seconds, and takes about 1 second to show when the infobox viewer is clicked.

That seems like a long time for that pattern. I imagine that pages with lots of viewers, like the various hassler pages or Lifeline issues, would load abysmally slowly. I had certainly noticed this when testing the layout of the Lifeline pages on my phone a few years back. I want the wiki to be accessible, and 10+ second page load times seem like they are a problem that should be dealt with.

Yes, the same problem happens for the hassler pages. It is very noticeable.
Here is what I got right now, when opening Honey farm hasslers on my laptop:

Code: Select all

LifeViewer lv-plugin.js:1620:202
refresh rate 60Hz lv-plugin.js:1288:392
read embedded: 489ms - lv-plugin.js:64:239
read embedded: 217ms - lv-plugin.js:64:239
read embedded: 159ms - lv-plugin.js:64:239
read embedded: 122ms - lv-plugin.js:64:239
read embedded: 160ms - lv-plugin.js:64:239
read embedded: 129ms - lv-plugin.js:64:239
read embedded: 100ms - lv-plugin.js:64:239
read embedded: 141ms - lv-plugin.js:64:239
read embedded: 162ms - lv-plugin.js:64:239
read embedded: 155ms - lv-plugin.js:64:239
read embedded: 130ms - lv-plugin.js:64:239
read embedded: 104ms - lv-plugin.js:64:239
read embedded: 168ms - lv-plugin.js:64:239
read embedded: 128ms - lv-plugin.js:64:239
read embedded: 168ms - lv-plugin.js:64:239
read embedded: 181ms - lv-plugin.js:64:239
read embedded: 180ms - lv-plugin.js:64:239
read embedded: 115ms - lv-plugin.js:64:239
read embedded: 71ms - lv-plugin.js:64:239
read embedded: 63ms - lv-plugin.js:64:239
read embedded: 44ms - lv-plugin.js:64:239
read embedded: 82ms - lv-plugin.js:64:239
read embedded: 97ms - lv-plugin.js:64:239
read embedded: 103ms - lv-plugin.js:64:239
read embedded: 68ms - lv-plugin.js:64:239
read embedded: 122ms - lv-plugin.js:64:239
read embedded: 109ms - lv-plugin.js:64:239
read embedded: 102ms - lv-plugin.js:64:239
read embedded: 73ms - lv-plugin.js:64:239
read embedded: 109ms - lv-plugin.js:64:239
read embedded: 71ms - lv-plugin.js:64:239
read embedded: 78ms - lv-plugin.js:64:239
read embedded: 64ms - lv-plugin.js:64:239
read embedded: 74ms - lv-plugin.js:64:239
read embedded: 65ms - lv-plugin.js:64:239
read embedded: 80ms - lv-plugin.js:64:239
read embedded: 68ms - lv-plugin.js:64:239
read embedded: 154ms - lv-plugin.js:64:239
read embedded: 120ms - lv-plugin.js:64:239
read embedded: 88ms - lv-plugin.js:64:239
read embedded: 83ms - lv-plugin.js:64:239
read embedded: 65ms - lv-plugin.js:64:239
read embedded: 79ms - lv-plugin.js:64:239
read embedded: 99ms - lv-plugin.js:64:239
read embedded: 74ms - lv-plugin.js:64:239
read embedded: 93ms - lv-plugin.js:64:239
read embedded: 90ms - lv-plugin.js:64:239
read embedded: 125ms - lv-plugin.js:64:239
read embedded: 151ms - lv-plugin.js:64:239
read embedded: 86ms - lv-plugin.js:64:239
read embedded: 64ms - lv-plugin.js:64:239
read embedded: 102ms - lv-plugin.js:64:239
read embedded: 89ms - lv-plugin.js:64:239
read embedded: 102ms - lv-plugin.js:64:239
read embedded: 84ms - lv-plugin.js:64:239
read embedded: 91ms - lv-plugin.js:64:239
read embedded: 67ms - lv-plugin.js:64:239
read embedded: 130ms - lv-plugin.js:64:239
read embedded: 172ms - lv-plugin.js:64:239
read embedded: 129ms - 2 lv-plugin.js:64:239
read embedded: 65ms - lv-plugin.js:64:239
read embedded: 47ms - lv-plugin.js:64:239
read embedded: 39ms - lv-plugin.js:64:239
read embedded: 60ms - lv-plugin.js:64:239
read embedded: 41ms - lv-plugin.js:64:239
read embedded: 58ms - lv-plugin.js:64:239
read embedded: 39ms - lv-plugin.js:64:239
read embedded: 61ms - lv-plugin.js:64:239
read embedded: 42ms - lv-plugin.js:64:239
read embedded: 85ms - lv-plugin.js:64:239
read embedded: 44ms - lv-plugin.js:64:239
read embedded: 105ms - lv-plugin.js:64:239
read embedded: 57ms - lv-plugin.js:64:239
read embedded: 83ms - lv-plugin.js:64:239
read embedded: 63ms - lv-plugin.js:64:239
read embedded: 81ms - lv-plugin.js:64:239
read embedded: 76ms - lv-plugin.js:64:239
read embedded: 94ms - lv-plugin.js:64:239
read embedded: 66ms - lv-plugin.js:64:239
read embedded: 93ms - lv-plugin.js:64:239
read embedded: 57ms - lv-plugin.js:64:239
read embedded: 85ms - lv-plugin.js:64:239
read embedded: 135ms - lv-plugin.js:64:239
read embedded: 172ms - lv-plugin.js:64:239
read embedded: 94ms - lv-plugin.js:64:239
read embedded: 83ms - lv-plugin.js:64:239
read embedded: 59ms - lv-plugin.js:64:239
read embedded: 96ms - lv-plugin.js:64:239
read embedded: 56ms - lv-plugin.js:64:239
read embedded: 92ms - lv-plugin.js:64:239
read embedded: 64ms - lv-plugin.js:64:239
read embedded: 89ms - lv-plugin.js:64:239
read embedded: 66ms - lv-plugin.js:64:239
read embedded: 97ms - lv-plugin.js:64:239
read embedded: 136ms - lv-plugin.js:64:239
read embedded: 71ms - lv-plugin.js:64:239
read embedded: 78ms - lv-plugin.js:64:239
read embedded: 62ms - lv-plugin.js:64:239
read embedded: 134ms - lv-plugin.js:64:239
read embedded: 100ms - lv-plugin.js:64:239
read embedded: 110ms - lv-plugin.js:64:239
read embedded: 116ms - lv-plugin.js:64:239
read embedded: 183ms - lv-plugin.js:64:239
read embedded: 137ms - lv-plugin.js:64:239
read embedded: 151ms - lv-plugin.js:64:239
read embedded: 76ms - lv-plugin.js:64:239
read embedded: 109ms - lv-plugin.js:64:239
read embedded: 60ms - lv-plugin.js:64:239
read embedded: 113ms - lv-plugin.js:64:239
read embedded: 75ms - lv-plugin.js:64:239
read embedded: 79ms - lv-plugin.js:64:239
read embedded: 90ms - lv-plugin.js:64:239
read embedded: 154ms - lv-plugin.js:64:239
read embedded: 150ms - lv-plugin.js:64:239
read embedded: 78ms - lv-plugin.js:64:239
read embedded: 98ms - lv-plugin.js:64:239
read embedded: 124ms - lv-plugin.js:64:239
page scan: 12503ms - lv-plugin.js:66:157

[rowett]

LifeViewer build 1233 brings further improvements to page scan speed.

I've measured the performance on my desktop machine which has a 5 year old CPU. Javascript is single threaded so single core performance is key.

Compared with build 1232:

• The large pattern Water_strider now scans 64% faster (180ms vs 296ms).
  • 1 pattern, 14023x7309, 47447 cells
• The Honey_farm_hasslers page now scans 110% faster (499ms vs 1051ms).
  • 118 patterns(!), around 50x50 each

These two pages are a good benchmark because they look at two different extremes (pattern size vs number of patterns).

confocaloid's published times were 5448ms (Water strider) and 12503ms (Honey farm hasslers) on build 1232. Please let me know your build 1233 times.

I'd also be interested in times from other machines.

Note: this thread title is now inaccurate. "LifeViewer load times" would be better.

[confocaloid]

LifeViewer build 1233 brings further improvements to page scan speed. [...]

Water strider : read embedded 2553 ms, page scan 2700 ms, 1 embedded
Honey farm hasslers : page scan 7119 ms, 118 embedded
viewtopic.php?f=2&t=4911 : page scan 4154 ms, 7 embedded
viewtopic.php?f=2&t=5286 : page scan 2536 ms, 0 embedded

[...]
I'd also be interested in times from other machines.

Note: this thread title is now inaccurate. "LifeViewer load times" would be better.

Additionally, this isn't a LifeWiki-only issue (e.g. forum threads with large patterns or many viewers are also affected), therefore the thread may belong more in "Website Discussion" rather than "LifeWiki Discussion".

[dvgrn]

... I wonder if it would be possible to have a LifeViewer option for thumbnails that only draws the pattern in generation 0 using the selected theme colors without loading up any of the rest of LifeViewer (so no animations, no annotations, and no evolving the pattern). The thumbnail could then still be clicked on to load the full LifeViewer.

Another option might be to somehow give the ability to create links on the wiki that, rather than go to another page, instead open the LifeViewer with the specified pattern. Then we could presumably have an ordinary static .png image in the infobox that would open the pattern in LifeViewer when clicked on. However, I'm not sure how easy this is to get working with MediaWiki.

Way back when Paul Callahan's Life pages were in their original form, Paul's Java applet replaced PNG thumbnails with an active simulation when you clicked to expand them.

Something like that seems like it would be a good solution in terms of minimal load time, but not so much for convenience in MediaWiki. It has been a huge relief to be able to get away from the separately uploaded and hard-to-maintain image files that used to be included as illustrations in a lot of article text.

Still, there might certainly be a few cases where showing an image would work well as the default, with a LifeViewer pattern load not happening until a user opts in with a click.

Now, 5 seconds is already a lot better from a usability perspective than 10-15 seconds, for sure. Maybe we'll eventually be able to come up with a set of (somewhat arbitrary) guidelines for when a pattern is too large to load reliably, or when the number of embedded viewers might start to impact usability?

Here are statistics collected for confocaloid's four sample links, from my home Windows 11 laptop -- Intel Core i7-8850H CPU (6 cores, 12 threads) @ 2.60GHz, 32 GB, Chrome 131.0.6778.265:

Water strider : read embedded: 384 ms, page scan: 397 ms, 1 embedded
Honey farm hasslers : read embedded: initial 13.5 ms, 117 more mostly around 5 ms each, page scan: 814 ms, 118 embedded
Exploratorium thread : read embedded: 289, 26, 16, 56, 13, 36 95 ms, read popup: 10, 1, 1, 1, 6, 3, 1 ms, 7 embedded
Oscillator stamp collection thread : read popup: 181, 2, 22, 1, 3, 10, 1, 12, 2 ms, page scan 245 ms, 0 embedded

The other thing that occured to me is only vaguely relevant, I think: besides building a separate article page containing an embedded LifeViewer to link to, there's a way to embed everything in one URL. Here's the text of the link:

Code: Select all

url=https://conwaylife.com/?rle=27b2ob2o$27bo3bo$28b3o$16bobo5b2o7b2o5bobo$14bo3bobo3b2o7b2o3bobo3bo$12bo2bo4bobo2bo2b3o2bo2bobo4bo2bo$10bo2bobo4bo2b3obobobob3o2bo4bobo2bo$11bob2o4b2obobo3bobo3bobob2o4b2obo$8bob2o10bo5b3o5bo10b2obo$7bob2o6b5ob5o3b5ob5o6b2obo$8b2obob2obobo3bo2bobo3bobo2bo3bobob2obob2o$11b3o3bob2obo2b3o3b3o2bob2obo3b3o$6b3o5bo2b3o2b3o3b3o3b3o2b3o2bo5b3o$6bo2bo3bob2o5bobo3bobo3bobo5b2obo3bo3bo$8b2o3b2obo2bo2b3o2bobobo2b3o2bo2bob2o4b2obo$10b2obob2obob2o3b2obobob2o3b2obob2obobo4bo$10bo2bobo3bobo3bobo3bobo3bobo3bobob5o$8b2o2b2o5b2obobob2o3b2obobob2o5bo6b3o$7bo6b5o2bobobo2b3o2bobobo2b5ob5o4bo$4b2o2b3ob2o2bobo3bobo3bobo3bobo3bobo2bo3bo3bobo$3bo2b2o2b2obo2b3o3b2obo2b3o3b2obo2b3o2bob2ob2obob2o$3b3o2b4o2b2o3b3o2bob2o3b3o2bob2o3b3o2b4obo$6bobo4bobo3bobo3bobo3bobo3bobo3bobo7bo$5b2obo3b4o3b3o2bobobo2b3o2bobobo2b3o2bo4bob2o$6b2o2b2o4b3o3b2obobob2o3b2obobob2o3b2obo2b2ob2o$7bo3b2o3bobo3bobo3bobo3bobo3bobo3bob2o2bo$5bobob2ob2obobobobobobobobobobobobobobobobobobob2o$4bob2obo4bobobobobobobobobobobobobobobobobobo2bob2o$4bo5bob2obo3bobo3bobo3bobo3bobo3bobo7bobo$2b2ob3ob2o2b3o3b2obobob2o3b2obobob2o3b2obob4o4bo$3bobo2bobo5b3o2bobobo2b3o2bobobo2b3o2bobo4b5o2bo$2bo2b2ob3o2bo2bobo3bobo3bobo3bobo3bobo3bob2obo5b3o$2b2obobo3b2obob3o3b2obo2b3o3b2obo2b3o3b3o2b2ob3o$2o5bo3bobo5b3o2bob2o3b3o2bob2o3b3o5bobo2bob2o$o2b3obo2bobobobo2bobo3bobo3bobo3bobo3bobo2bo2b3ob2o2bo$b2o2b2ob2obobobobob3o2bobobo2b3o2bob2o3b3obob2o3bobo$3bobo2bobo3bobo5b2obobob2o3b2obo2b3o5bobo3bo3bo$3bobo2b2obobobobobo2bobo3bobo3bobo3bobo2bobobobo2bobo$2b2o2bo2bobo2bobobobob2obobobobobobobo2b3obobobobob2ob2o2bo$4b2o5bo5bobo3bobo2bobobobobob2o5bobo3bobo2bob2o$4bob4ob4obob2o5bo5bobo3bobo2bobobobobob2ob3o$5b2o3bo4bobo2b4ob4obobobobob2obobobobo2bobo5b2o$8bo2bob2obo3bobo4bobob3o2bobo3bobo5bo5bobo$5b2ob2obo2b3o3b2o2b2o2b2o6bo5b2obob4obob3o2bo$6bo4bo5b3o2bobo3b2o2b3obob4o2bobo5b2o3b2o$6bob3o3bobo2bo2bobo6bobo3bobobo3bob2ob2o3b2o$7bo3b2ob4ob3obo3bobob2ob2obo2b2o3b3o3bo4bo$8b2o3bo5bob2o3bob2o2bob2obobo2b3o5bo4bo$10b3ob3o9bo3b2o5bobobo3bobo2bobobo$10bo2bobo2bo2b2o4b3o7bob4ob4ob2ob2o$13bo3b2obo2bo5bo5b2obo8bo3bo$14b3o3bobo12bo2bobo2bo2bob2obo$16bo3b2o15b2ob2o3b2obobo&name=Unsynthesizable oscillator 1

[confocaloid]

[...] Maybe we'll eventually be able to come up with a set of (somewhat arbitrary) guidelines for when a pattern is too large to load reliably, or when the number of embedded viewers might start to impact usability? [...]

When a pattern is large, not only it can load slowly, but it would also display so that the details are not visible.

As an extreme example, in the articles block, blinker, glider, R-pentomino, the individual cells of patterns shown in the infobox are clearly visible. Each of those patterns is clearly small enough to be put in the respective infobox.

On the other hand, a pattern such as Breeder 1 is already too large to reasonably fit in the infobox. It is better to put a pattern of that size outside the infobox, later down in the page, so that the embedded viewer can be much wider than the infobox.

The recently discovered 31c/240 spaceships are much larger than that, and therefore also too large for the infobox. The details simply aren't visible anymore.
A download link can be provided without showing the large pattern immediately. The large pattern can be put in a separate page (along with brief comments / description and links to sources to provide context), so that a LifeWiki reader can choose whether to view the large pattern or to read only the article describing it.

[rowett]

Now, 5 seconds is already a lot better from a usability perspective than 10-15 seconds, for sure.

Actually from confocaloid's results we're down to 2.7 seconds for the Water strider. There is more to come...

Here are statistics collected for confocaloid's four sample links, from my home Windows 11 laptop -- Intel Core i7-8850H CPU (6 cores, 12 threads) @ 2.60GHz, 32 GB, Chrome 131.0.6778.265:

Water strider : 397 ms
Honey farm hasslers : 814 ms
Exploratorium thread : 554ms
Oscillator stamp collection thread : 245 ms

Thanks for the data. For reference here are the page scan times for build 1233 from my devices (EDIT: added LifeViewer Pro times):

1. Windows 11 desktop -- AMD Ryzen 9 3950X CPU (16 cores, 32 threads, Q4 2019) @ 3.50GHz, 64GB, Chrome 132
   • Water strider : 197ms (Pro 128ms)
   • Honey farm hasslers : 491ms (Pro 383ms)
   • Exploratorium thread : 300ms
   • Oscillator stamp collection thread : 224ms
2. Windows 11 desktop -- AMD Ryzen 7 5800X (8 cores, 16 threads, Q4 2020) @ 3.80GHz, 16GB, Brave 1.74
   • Water strider : 297ms
   • Honey farm hasslers : 473ms
   • Exploratorium thread : 281ms
   • Oscillator stamp collection thread : 201ms
3. Windows 11 laptop -- Intel Core i7-10510U (4 cores, 8 threads, Q3 2019) @ 2.30GHz, 16GB, Chrome 132
   • Water strider : 272ms
   • Honey farm hasslers : 697ms
   • Exploratorium thread : 424ms
   • Oscillator stamp collection thread : 204ms
4. MacBook Pro M1 macOS 15.3 -- Apple M1 CPU (4 performance cores, 4 efficiency cores, Q4 2020), 16GB, Safari 18.3
   • Water strider : 204ms
   • Honey farm hasslers : 515ms
   • Exploratorium thread : 260ms
   • Oscillator stamp collection thread : 144ms
5. Windows 10 desktop -- Intel Core i5-3450 CPU (4 cores, 4 threads, Q2 2012(!)) @ 3.50GHz, 16GB, Chrome 132
   • Water strider : 337ms
   • Honey farm hasslers : 978ms
   • Exploratorium thread : 535ms
   • Oscillator stamp collection thread : 269ms
6. Windows 11 laptop (dvgrn) -- Dell Precision 3581, 13th Gen Intel Core i7-13800H, 2500 Mhz, 14 cores, 20 logical processors:
   • Water strider read embedded: 226 ms, page scan: 237 ms (Pro read embedded: 220 ms, page scan: 230 ms)

The venerable 13 year old Windows 10 desktop is now sub-second for the Honey farm hasslers scan.

[dvgrn]

The recently discovered 31c/240 spaceships are much larger than that, and therefore also too large for the infobox. The details simply aren't visible anymore.

What I want to see in the infobox for the water strider spaceship is the overall shape. That's showing up quite nicely. When I want to look at more detail, I can click on the infobox LifeViewer and zoom in to the part I want to study. That works great for me on a desktop or laptop. When I tried it on a mobile device just now, I still got load times under one second, and I was able to zoom in and look at individual Herschel-climber interactions with no trouble, with the simulation running at an appropriate speed. I have what counts as a moderately ancient Android phone, a Google Pixel 4a.

All other things being equal, I'd like to keep those pieces of functionality in the article. Now, maybe all other things aren't equal, but it doesn't seem like we know that yet.

What fraction of conwaylife.com users and LifeWiki users are actually having any significant trouble with slow load times? What would be a good way to find that out?

Even before rowett's significant improvements recently, there haven't been a lot of people complaining about slow load times. It seems possible that this is because most users are seeing sub-one-second load times. If a few people are seeing somewhat slow but tolerable load times but a lot of people are benefitting from the functionality that LifeViewer is providing, at some point that's going to be a reasonable tradeoff. It just seems like an open question whether we've reached that point yet.

[rowett]

LifeViewer Pro with the Water strider can be tested here. The page scan time will be displayed on the window under "Alpha release".
Please ensure the console window is not open since it adversely affects LifeViewer Pro performance.

My main desktop machine, number 1 in the list above, now takes 128ms (vs 197ms for LifeViewer Standard) which is a 53% improvement.

@dvgrn, @confocaloid and anyone else interested: please post your results here.

[confocaloid]

LifeViewer Pro with the Water strider can be tested here. The page scan time will be displayed on the window under "Alpha release".
Please ensure the console window is not open since it adversely affects LifeViewer Pro performance.
[...]

On my laptop, the displayed page scan time varies around 3.4 to 4.4 seconds.
From my measurements, the real clock time appears to be roughly 4 to 7 seconds.
I tried clicking "Launch" on the viewer. Launching takes around 10 to 12 seconds.

[b-engine]

Despite running Chrome 132 on Android 9, I still get LifeViewer Standard instead of Pro; whatever problem happened?