perf(plugin): `hstr::Atom` has very inefficient serialization/deserialization logic

[kdy1]

Currently, it creates a String each time it's serialized, but rkyv supports shared-pointer string serializarion.

swc/crates/hstr/src/lib.rs

Lines 387 to 418 in 6c68a1e

	/// NOT A PUBLIC API
	#[cfg(feature = "rkyv")]
	impl rkyv::Archive for Atom {
	type Archived = rkyv::string::ArchivedString;
	type Resolver = rkyv::string::StringResolver;
	#[allow(clippy::unit_arg)]
	unsafe fn resolve(&self, pos: usize, resolver: Self::Resolver, out: *mut Self::Archived) {
	rkyv::string::ArchivedString::resolve_from_str(self, pos, resolver, out)
	}
	}
	/// NOT A PUBLIC API
	#[cfg(feature = "rkyv")]
	impl<S: rkyv::ser::Serializer + ?Sized> rkyv::Serialize<S> for Atom {
	fn serialize(&self, serializer: &mut S) -> Result<Self::Resolver, S::Error> {
	String::serialize(&self.to_string(), serializer)
	}
	}
	/// NOT A PUBLIC API
	#[cfg(feature = "rkyv")]
	impl<D> rkyv::Deserialize<Atom, D> for rkyv::string::ArchivedString
	where
	D: ?Sized + rkyv::Fallible,
	{
	fn deserialize(&self, deserializer: &mut D) -> Result<Atom, <D as rkyv::Fallible>::Error> {
	let s: String = self.deserialize(deserializer)?;
	Ok(Atom::new(s))
	}
	}

[kdy1]

cc @quininer

Regarding #11100 and #11198, does this still apply after merging those PRs?

i.e. Does the new serilalization format support a shared-pointer string serialization?

[quininer]

No, CBOR doesn't support this; it's just like JSON but in binary format.

If we are to support this, it would look better to use an external string pool and a string ID.

[kdy1]

String pool sounds good. I'll keep this PR open. I have implemented one for turbopack, so it's not a hard task for me.