- unclaimed are shown when we ask for L1
- helps preserve more data as you zoom out and links create 'placeholder' portals we already have more data for
increase the number of items rendered in the render queue batches - should make IITC render a bit faster, especially now that the portals have gone and instead there's a fair amount of duplicate data from links/fields across multiple data tiles
also, better warning when failing to extract tile parameters from stock - as if this fails it's probably because the values have changed and IITC will break
maybe Niantic should have load-tested the best values in dev before releasing into production, rather than repeatedly changing it so many times?
or at least made it completely controlled by server-side code, so no client updates needed for every experimental change...
iitc detects the correct map params anyway, but warns when fallback values are different
also, new data in portal entities - unknown12 (only seen 'null') and index 13 (portal timestamp)
the timestamp is also in the portal details, so this will be handy
more people ask about what this prompt is about, and answering 'no' generally breaks botguard at this point.
if you don't like the possibility of IITC running server-returned code, then disable the botguard interface completely - we're already running it on page load, so there's no more risk doing it here too
console warnings when it fails to detect values from stock, or the internal defaults don't match
disable show-more-portals plugin if it would result in more requests - damn niantic!
this shouldn't be needed - the stock intel map completely ignores these so they shouldn't be returned - but since niantic added mission portals to the map they bypass all portal level filtering code, for some reason
On older machines loading high portal dense areas this check is
using 70-90% of CPU in Object.keys(cache).length, leading to
resource starvation, and refresh times up to 10 times longer.
The LRU cache high-water mark is checked every time we receive portal
state from the intel servers to see if we need to do GC. In
my case this peaks out 500-1000 portal adds per second on
an aging laptop with the existing code with chrome-unstable,
and minimal IITC plugins. GC itself (ignoring v8 GC) was only
taking 15ms, amortized to about 15usec a portal.
Unforutnately the Object.keys(cache).length check was taking
2-3ms each portal add, and 70-90% of the main thread was spent
there, grinding older machines to a halt.
I've just added a counter to track adds to the cache, and am
updating it with the real cache size on GC (the two checks
are almost always identical in higher density areas, and
won't lead to performance issues if cache adds are over-
estimated).
Effects:
- pushPortalGuidPositionCache goes from using the majority
of CPU when loading dense areas to almost nothing.
- Older machines can actually view western europe without
grinding the browser to a halt.
- the cache itself is now hitting GC_LIMIT in less than
100ms on my old laptop. (I think increasing GC_LIMIT
to 80,000 and GC_KEEP to 40,000 is going to put less
load on the Javascript engine GC, and have the cache
be useful still, but I left that out of the PR as it's
slightly more subjective)
- v8's GC is being slammed slightly less often than normal
(it's still thrashing, but this isn't the main culprit)
The patch has been tested by about half a dozen people
using different blends of IITC plugins on both Chrome,
Firefox and across different OSs and with very different
hardware. Reports ranged from minor to (more often) huge
improvements in load speed and responsiveness in high
density areas.
