[Tickets #13761] Re: Memory usage issues when IMAP sequence range is far apart

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: https://bugs.horde.org/ticket/13761
------------------------------------------------------------------------------
  Ticket             | 13761
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | Memory usage issues when IMAP sequence range is far
                     | apart
  Queue              | IMP
  Version            | 6.2.4
  Type               | Bug
-State              | Assigned
+State              | Feedback
-Priority           | 2. Medium
+Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael Slusarz
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2014-12-21 18:51) wrote:

> Ive had an issue with one user where the range was over 1m between  
> min & max and the max memory had to be over 256Mb

They have 1 million messages in their mailbox?  The expectation for a  
mailbox that large MUST be that it is going to take a lot of memory.

> Using SplFixedArray the max memory limit can be reduced to about  
> half but there are big issues elsewhere as the Spl does not have all  
> the sort functions that a standard array has.

That's exactly the issue.  You can optimize for memory, but then you  
lose speed.

Since most people have mailboxes less than 1 million messages, the  
obvious choice is to optimize this scenario.

Not to mention that there is very little you can do when working with  
a list of messages that may NOT be in sequential order.  i.e. a 1  
million element UID list where every other UID is skipped.

Doing things like binary packing and in-line compression are possible  
options, but these are complicated additions and not something that I  
am going to tackle unless someone is paying me.

> Another problem is found on line 170, would it not be prudant to  
> unset each array key as it is populated into the _add array, that  
> way the memory should not balloon (not sure if PHP optimises for  
> this anyway).

This is irrelevant for PHP memory handling.  There is no direct access  
to PHP memory/garbage collection that's going to make a difference in  
this situation.