diff options
author | Eric Wong <e@80x24.org> | 2021-10-23 18:20:44 -0600 |
---|---|---|
committer | Eric Wong <e@80x24.org> | 2021-10-24 02:20:33 +0000 |
commit | 08b543eb6c67cc19ea8e86afe6b9494df79e2fea (patch) | |
tree | 12178b7b3dd008b630d31175f3e6684202397e1e /lib/PublicInbox/SearchView.pm | |
parent | a877fe97c753e7dc1803936e932adff566f7641d (diff) | |
download | public-inbox-08b543eb6c67cc19ea8e86afe6b9494df79e2fea.tar.gz |
The use of array-returning built-ins such as `grep' inside arrayref declarations appears to result in permanently allocated scratchpad space for caching according to my malloc inspector. Thread skeletons get discarded every response, but multiple skeletons can exist in memory at once, so do what we can to prevent long-lived allocations from being made, here. In other words, replacing constructs such as: my $foo = [ grep(...) ]; with: my @foo = grep(...); Seems to ensure the mortality of the underlying array.
Diffstat (limited to 'lib/PublicInbox/SearchView.pm')
-rw-r--r-- | lib/PublicInbox/SearchView.pm | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/lib/PublicInbox/SearchView.pm b/lib/PublicInbox/SearchView.pm index a42867c5..b1cdb480 100644 --- a/lib/PublicInbox/SearchView.pm +++ b/lib/PublicInbox/SearchView.pm @@ -274,10 +274,10 @@ sub search_nav_bot { # also used by WwwListing for searching extindex miscidx } sub sort_relevance { - [ sort { + @{$_[0]} = sort { (eval { $b->topmost->{pct} } // 0) <=> (eval { $a->topmost->{pct} } // 0) - } @{$_[0]} ] + } @{$_[0]}; } sub mset_thread { |