Computer/builds.jelly calls Computer.getBuilds which first looks up all Job instances—probably not too expensive—then creates a merged RunList from them—again OK, as this is lazy—then calls the node(Node) filter. The filter is incremental, but if most builds were not on this computer, it would load many more than the limit of 50 in t:buildListTable before it finds some to display.

Trimming the merged list before filtering would solve that problem (making this perform much like View/builds.jelly), but then you might not see anywhere near 50 builds, or indeed any at all, even when there are some (older) builds run on this computer.

User/builds.jelly calls User.getBuilds which does not even bother using an incremental filter. It does use newBuilds to limit how many builds are considered per job, but then scans all of those at once for mentions of the current user.

Ideally all such displays would show all applicable builds, but use ProgressiveRendering so that build records are only loaded in a background thread and only so long as you keep the page open. (Compare AsynchPeople.)