I'm currently working on some improvements in our code e.g. to make possible to open a folder with 100k messages and make memory_limit to not exceed on this operation.
I've found that we have one optimization for messages listing. It's used when skip_deleted=false and message_sort_col='' and no threading. So, this is a corner case when we don't need to fetch the list of message UIDs nor IDs from server, but we build the array of IDs on range(1, $max), see line 1529 of rcube_imap.php.
This solution is good for performance in this one case, but if we could get rid of it and always work with UIDs only, we would have much simpler code and possibly more performant in other places (including caching) because there would be no need for id-to-uid mapping.
The problem is that in described case we'd need to call UID SEARCH ALL. Even so, I think it's worth to do this. Any thoughts on this?
On Wed, Nov 30, 2011 at 19:40, A.L.E.C alec@alec.pl wrote:
I'm currently working on some improvements in our code e.g. to make possible to open a folder with 100k messages and make memory_limit to not exceed on this operation.
I've found that we have one optimization for messages listing. It's used when skip_deleted=false and message_sort_col='' and no threading. So, this is a corner case when we don't need to fetch the list of message UIDs nor IDs from server, but we build the array of IDs on range(1, $max), see line 1529 of rcube_imap.php.
This solution is good for performance in this one case, but if we could get rid of it and always work with UIDs only, we would have much simpler code and possibly more performant in other places (including caching) because there would be no need for id-to-uid mapping.
Any information about the support of UID search with ranges (e.g. UID 83:*) in the current IMAP servers?
The problem is that in described case we'd need to call UID SEARCH ALL. Even so, I think it's worth to do this. Any thoughts on this?
Would the result of UID SEARCH ALL be small enough to fit into memory?
But in general I think we should follow this idea and if it turns out, that IMAP backend support is granted, it would certainly simplify things.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
On Wed, Nov 30, 2011 at 19:40, A.L.E.C alec@alec.pl wrote:
I'm currently working on some improvements in our code e.g. to make possible to open a folder with 100k messages and make memory_limit to not exceed on this operation.
I've found that we have one optimization for messages listing. It's used when skip_deleted=false and message_sort_col='' and no threading. So, this is a corner case when we don't need to fetch the list of message UIDs nor IDs from server, but we build the array of IDs on range(1, $max), see line 1529 of rcube_imap.php.
This solution is good for performance in this one case, but if we could get rid of it and always work with UIDs only, we would have much simpler code and possibly more performant in other places (including caching) because there would be no need for id-to-uid mapping.
Any information about the support of UID search with ranges (e.g. UID 83:*) in the current IMAP servers?
Works fine in dovecot:
. UID search 83:86
- SEARCH 450965 450966 450967 450968
Alec, is there a reason to allow for no-sorting? Isn't that pretty much the same as sorting date column on arrival? For dovecot sorting date on arrival is super fast.
Im fine with removing the special case if that helps RC.
Cor
List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 06.12.2011 11:50, Cor Bosman wrote:
Alec, is there a reason to allow for no-sorting? Isn't that pretty much the same as sorting date column on arrival? For dovecot sorting date on arrival is super fast.
Not all servers support SORT. Also building an index array in php is still faster than SORT.
On 06.12.2011 11:34, Thomas Bruederli wrote:
Any information about the support of UID search with ranges (e.g. UID 83:*) in the current IMAP servers?
Do you know any that doesn't support this?
The problem is that in described case we'd need to call UID SEARCH ALL. Even so, I think it's worth to do this. Any thoughts on this?
Would the result of UID SEARCH ALL be small enough to fit into memory?
Currently we use "SEARCH ALL UNDELETED" in some cases and it works, so I don't see a problem. I'm working on result handling objects that store result as string in memory, so memory consumption will be even less than now.
On Tue, Dec 6, 2011 at 13:13, A.L.E.C alec@alec.pl wrote:
On 06.12.2011 11:34, Thomas Bruederli wrote:
Any information about the support of UID search with ranges (e.g. UID 83:*) in the current IMAP servers?
Do you know any that doesn't support this?
No I don't but I haven't investigated on that. That's why I asked this question here.
The problem is that in described case we'd need to call UID SEARCH ALL. Even so, I think it's worth to do this. Any thoughts on this?
Would the result of UID SEARCH ALL be small enough to fit into memory?
Currently we use "SEARCH ALL UNDELETED" in some cases and it works, so I don't see a problem. I'm working on result handling objects that store result as string in memory, so memory consumption will be even less than now.
I guess in order to issue select commands for a specific page, we still need the UIDs as a list where we can extract a slice. But that's an implementation detail.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
-
A.L.E.C -
Cor Bosman -
Thomas Bruederli