Which JMeter listeners keep a copy of every sample, and which one is built for a load run?

## One test element wearing several faces In a JMeter `.jmx`, **View Results Tree**, **View Results in Table** and **Simple Data Writer** are the same test element. All three save as `testclass="ResultCollector"` and differ only in the `guiclass` attribute that names the panel bolted to it: ```xml <ResultCollector guiclass="ViewResultsFullVisualizer" testclass="ResultCollector" testname="View Results Tree"/> <ResultCollector guiclass="TableVisualizer" testclass="ResultCollector" testname="View Results in Table"/> <ResultCollector guiclass="SimpleDataWriter" testclass="ResultCollector" testname="Simple Data Writer"/> ``` The `ResultCollector` half is identical in all three: it decides whether the sample is wanted, and if a filename is set it writes one record. The `guiclass` half is where the difference lives, and it is the half that decides whether the sample result is **kept**. ## Which listeners retain, and which do not The manual states it plainly: *"Listeners can use a lot of memory if there are a lot of samples. Most of the listeners currently keep a copy of every sample in their scope"* — and then names the exceptions. | Listener | What it does with each sample | |---|---| | View Results Tree | Buffers whole sample results so you can click one and read the response | | View Results in Table | Appends a retained row per sample result | | Simple Data Writer | Nothing — its `add(SampleResult)` is documented as *"Does nothing, but required by interface"* | | BeanShell / JSR223 Listener | Runs your script against the sample, keeps nothing itself | | Summary Report, Mailer Visualizer | Keep running figures, not the samples | | Aggregate Report, Aggregate Graph | Aggregate samples that share an elapsed time rather than storing each one | So the split is not "GUI versus file". Simple Data Writer *is* a GUI element; it simply has no panel that needs the sample afterwards, which is exactly what the manual means when it calls it *"an efficient means of recording data by eliminating GUI overhead"*. ## Why retention is the expensive half A retained sample result is not a row of numbers. It is the whole `SampleResult` object, and it carries the response bytes, the request that produced them, the assertion results and any sub-samples hanging off it. Holding it is what stops the garbage collector from reclaiming a response body that the plan has already finished with. A page sampler that fetches embedded resources makes this worse: the child results travel inside the parent, so one retained entry can be dozens of results. The writing half, by contrast, is bounded work: format one record, hand it to a buffered writer, forget the object. That is why the listeners sit near the top of the manual's list of ways to reduce resource usage, above anything about the file itself. ## Disabling is not a half-measure Unticking **Enabled** on a listener is not a cosmetic change. When JMeter converts the plan into the tree the engine runs, it walks the tree and drops every element whose Enabled flag is false, before a single thread starts. A disabled listener is therefore not in the plan at all — it costs nothing, and it is still there in the file when you next open the plan to debug it. Deleting it and disabling it are equivalent at run time. ## What a load plan should carry - **Nothing that retains**, as a default. View Results Tree and View Results in Table belong to the scripting phase, and the manual says so directly: use them only while debugging your script. - **One lean writer**, if the plan needs a listener element at all — a Simple Data Writer with CSV output, writing only the fields the analysis will actually read. (Which fields those are, and the keys that select them, is the result-file topic, not this one.) - **Errors only**, where a listener must stay for evidence. Every listener panel built on a `ResultCollector` — the results tree, the table, the aggregate and summary reports, the Simple Data Writer — carries a *Log/Display Only* pair of checkboxes, **Errors** and **Successes**, mutually exclusive, and the filter runs before both the display and the file write, so an errors-only listener does nothing at all on a successful sample. The listeners that are not visualizers have no such pair: the Backend Listener, Generate Summary Results and the script listeners carry no filter of their own, and *Save Responses to a file* carries its own **Save Failed Responses only** box instead. - **No listener at all**, when the run is driven from the command line with a result file: the manual notes that in that case the listeners *"can all be deleted or disabled"*. The habit worth building is to ask, of every listener in the plan, *what does this keep?* rather than *what does this show?* The showing is free once the run is over; the keeping is paid for during it, on the injector, at exactly the moment you are trying to measure something else.