How can you optimize a JMeter test plan that relies heavily on BeanShell elements?

Migrate the highest-iteration-count BeanShell elements to JSR223 with Groovy first, since those are exactly the elements where BeanShell's lack of cached compilation causes the most cumulative overhead - a script that runs once per test setup benefits far less from migration than one running on every iteration of a high-thread-count Thread Group.

For BeanShell elements you keep, minimize the amount of logic actually inside the script itself - move substantial or reusable logic into a proper compiled Java class the script merely calls into, rather than interpreting a large block of logic fresh on every execution.

Avoid unnecessary object creation and heavy computation inside a BeanShell script's hot path specifically, since interpretation overhead compounds with whatever computational cost the logic itself carries - a script that's both interpreted fresh each time and doing expensive work each time pays a double cost compared to a leaner equivalent.

Benchmark before and after any migration on a representative subset of the test plan, rather than assuming migration is always worth the effort uniformly - for low-iteration-count elements, or ones only touched rarely, the practical performance gain from migrating may be too small to justify the engineering time, so prioritizing based on actual measured impact is more efficient than converting every BeanShell element indiscriminately.