More strategic useMemo usage to improve code readability and performance

[krista-koivisto]

There is currently a fair bit of unnecessary useMemo use in the codebase. It creates a cluttery codebase that may be off-putting to would-be contributors while not actually leading to improved performance. It will even hurt performance due to the overhead of the hook in many cases.

Here is an example of such a case:

StableStudio/packages/stablestudio-ui/src/Generation/Image/index.tsx

Lines 153 to 165 in 76772d7

	const specialEffects = useMemo(
	() => (
	<Image.SpecialEffects
	showing={shouldShowSpecialEffects}
	loading={!placeholder && shouldShowSpecialEffects}
	variant={(style.height ?? 512) < 48 ? "small" : undefined}
	// example={example}
	// onClick={example ? onTryTemplate : undefined}
	// input={currentInput?.id}
	/>
	),
	[placeholder, shouldShowSpecialEffects, style.height]
	);

In this case, the overhead of useMemo is going to be significantly worse than letting React discover on its own that it doesn't need to rerender the component. useMemo should ideally be used sparingly and for truly resource-intensive tasks, or in some special cases such as ensuring referential equality.

It is also (almost always) a bad idea to wrap the return statements of functional components in useMemo as React is VERY good at knowing when it needs rerender components.

I really think it would be good to clean this up if it is okay with the product owner(s). Doing so would lead to a friendlier codebase that may attract more contributors and would likely make StableStudio more optimized in the process.

[charkour]

I'm curious if you have quantitative data about the overhead in this particular case. Could you add that if you do?

[krista-koivisto]

@charkour That is a very valid question.

Unfortunately the official React documentation doesn't go into more detail than suggesting it be used for "expensive" calculations. However, I did find an attempt at quantifying the performance. The main takeaways from that article is:

• It may hurt performance by up to 11% when used in excess
• Most of the time it won't matter
• With more expensive calculations it is definitely worth it

The real issue that I see with premature optimization is the poor developer experience resulting from it. The potential gain in processing time is not significant enough to offset the cost in developer time. That time can later be used to optimize where it truly is necessary.

[charkour]

Roger, thank you for the write-up! Looks like the maintainers aren't super active here, but I appreciate you raising concerns!