src_url_equal is slow when dealing with large base64 encoded images

[EmilTholin]

Describe the bug

This discussion on Discord made us realize that trying to remove an element from an each block containing images with large base64 encoded images takes a long time.

This is because the src_url_equal check in the generated code is slow for these types of images.

if (dirty & /*images*/ 1 && !src_url_equal(img.src, img_src_value = /*image*/ ctx[3].src)) {
	attr(img, "src", img_src_value);
}

svelte/src/runtime/internal/utils.ts

Lines 45 to 53 in 4b84c4d

	let src_url_equal_anchor;
	export function src_url_equal(element_src, url) {
	if (!src_url_equal_anchor) {
	src_url_equal_anchor = document.createElement('a');
	}
	src_url_equal_anchor.href = url;
	return element_src === src_url_equal_anchor.href;
	}

Reproduction

REPL

Logs

No response

System Info

REPL, v3.55.0

Severity

annoyance

[Conduitry]

I don't remember why we were doing it this way. To support older browsers without the URL global I'm guessing? Do you get the same behavior if you compare element_src === new URL(url, document.location).href (and is that appreciably faster)? Maybe we could have two versions of this code and use the URL global if it's available.

[dominikg]

we should try to avoid doing any assignments that are not needed in this case. If this is only relevant for relative/absolute conversion, testing that url is indeed relative and does not start with a protocol would be the first thing that comes to my mind to prevent this. Using URL instead of a is just a slight difference in implementation, which is slightly slower according to this comment: #6449 (comment)

[EmilTholin]

I experimented with an overly-simplistic src_url_equal, and the difference in speed was almost negligible.

export function src_url_equal(element_src, url) {
+	return element_src === url;
-	if (!src_url_equal_anchor) { 
-		src_url_equal_anchor = document.createElement('a'); 
-	} 
-	src_url_equal_anchor.href = url; 
-	return element_src === src_url_equal_anchor.href; 
} 

I guess comparing all these long strings against each other is slow no matter how you do it.

It is really fast in the Svelte 5 preview REPL though (I can't share it because the base64 image is too big for the URL) because of the fine-grained array updates, so this will not be an issue going forward.