Why should you avoid heavy business logic inside BeanShell PreProcessors?

BeanShell's per-execution interpretation overhead, without cached compilation, means a PreProcessor with substantial logic pays that interpretation cost on every single iteration of every thread it runs on, which compounds quickly into meaningful overhead at realistic load-test thread counts and iteration counts.

Beyond raw performance, embedding significant business logic directly in a script inside a test plan also hurts maintainability - it's harder to version, review, test, and reuse compared to logic implemented as a real, compiled Java class or a properly structured JSR223/Groovy script with appropriate tooling support.

The generally recommended pattern is to keep BeanShell, or any scripting element, logic focused on lightweight glue work - simple extraction, a small conditional, a quick transformation - and push genuinely complex or substantial logic into a dedicated Java class the test plan can call into, or at minimum into a JSR223/Groovy element that benefits from script caching.