Pegasus Mail & Mercury

I've been suffering with slow New Mail folder open times. After receiving new mail, it can take fro 20-40 seconds (or more) before the contents are displayed. I currently have 552 new messages and 60 filter rules applied on folder open. My processor is 2.6gHz dual and I have 1.5gb of ram. Nothing else is running when I try the open. As a matter of fact, if I try to do anything else I get no response until Pegasus is through. I have found that setting the winpn-32.exe process affinity to just one processor AND lowering its priority to BelowNormal helps a little bit. OS is XP Pro SP3. My inbox has been fatter (up to around 1200) in the past. Is there any way to compress the inbox? Is it even necessary? Once the folder has been opened, it reopens quickly until new email arrives. Too many filter rules?

btw - I've been a Pegasus user since 1995. I even have a horse named Pegasus. Don't worry - I'm not that crazy. I got him years before Pegasus email came around. 

Is there any way to compress the inbox? Is it even necessary? Once the folder has been opened, it reopens quickly until new email arrives. Too many filter rules?

Too much mail in the inbox and probably too many filters searching for body text as well.   Each time a new message arrives all mail is scanned, and if you are searching the body of the mail with any filter,  message with attachments really slow this down.  If you would move some of this mail out to a separate folder then the slowdown will go away.

---

Thomas R. Stephenson
San Jose, California
Member of Pegasus Mail Support Team

I do not answer private messages from the forum. If you want to contact me use email to techsupp@tstephenson.com.

Ken Kaplan:

... after receiving new mail, it can take fro 20-40 seconds (or more) before the contents are displayed. ...

 ... which also happens when you open New Mail after receiving mail.  The reason is here:

Ken Kaplan:

... btw - I've been a Pegasus user since 1995. I even have a horse named Pegasus. ...

 I mean the "since 1995"; not the horse.

Here's the fix:

---

In the ..\pmail\mail folder, There's a file named  HIERARCH.PM

1. Close Pegasus.  (You will be editing one of Pegasus' control files.)
   
2. Copy  HIERARCH.PM and rename one of the files !HIERARCH.PM (or however you like to mung filenames.  The only reason to do this is in case something goes wrong, you have the original as a backup.)
3. Open HIERARCH.PM in a text editor.
4. Visually search for all instances of "Name_Unavailable" including instances with values appended (e.g., "Name_Unavailable,0,20"), and delete those lines.  This will take about 10 minutes or longer.
   
5. Do the same thing with the text editor's search function (search for "Name_") and delete the lines you missed in your visual search.
6. Close HIERARCH.PM and launch Pegasus.
   

By now, you already know to periodically move "New Mail" to archive, which also speeds loading.

This "Name_Unavailable" issue also seems to explain why "New Mail" takes longer to load than other bloated folders.

---

 

addendum

It seems that the New Mail folder is still slow, but not as slow as with all of the "Name_Unavailable" artifacts parked in HIERARCH.PM. I created a new folder

"<space>New Mail - bloated"

to move new emails with attachments until I'm ready to file or delete them. That reduces the size of the New Mail folder.

Thanks for the HIERARCH.PM tip. I had about 50 of them.

Perhaps not much use to many people, but I recently found a solution to the slow new mail folder opening issue. My problem was/is caused by just having far too many new mails - 3400+ at the moment. Sure I could archive them, but this is the actual number of new/unread emails that need to be dealt with! Hiding them away does not help. Also, you can only delete attachments from new mails (but can move them back to new mail folder temporarily to do this).

The main reason for the slowness is that each new mail is a separate file, all stored at random places on your hard drive, which can take minutes to load. The loop which loads them seems to monopolise the filesystem with almost no CPU usage, so during the minutes while those are loading, nothing else will open (on XP and earlier). Once they are cached into RAM by the OS, loading is very quick. I got some relief from "Eboostr" - a readyboost type app for XP/2000 - about halved the first opening time.

My unexpected but obvious solution was to get a SSD. It can load thousands of files in a flash (no pun intended).

You need to be cautious about removing Name_Unavailable (N_U) entries if you
use added mailboxes.

If you open an added mailbox and disconnect it before closing Pmail then, on
closing Pmail, all references to the added mailbox become N_Us.

If you delete those NUs then the next time you "Add mailbox to list" then some
of the hierarchy for the mailbox that you formerly created will be lost.

It is not at all easy to determine which entries in HIERARCH apply to added
mailboxes. Although top level entries (trays or folders that are direct
children of the mailbox) can be detected by the presence of a string such as
z:\\pmail\\mail\\, lower level entries do not.

 Perfect, thanks for great tip,  I suffered from the same issue... slow opening Inbox, when e.g. returning from an other folder.. about 1000 messages there, windows always become unsable during that.  Tried (long time ago) all known tricks such as always loading winsock dll, opportunistic locks etc, was about to give it up but then finaly found this thread and edited the hiearchy.pm - switching folders /rescan inbox is now done immediately. 

Hi guys, lovely jobly over here, i am a newbie and i am finding this community really helpful already, i have being experincing some slowdown as well and as prescribed here, i am going to apply this immediately. Thanks again and see u guys here later.

 

 

Wow - just deleted those items, and it really speeds up Pegasus start times significantly!

Maybe move this to a Feature Request - automatically clean up the hierarchy.pm file?

 

Finally moved to the new 4.63 version (from 4.52 :)). Have had a lot of things on my mind the last year...

And starting up Pmail shows the user interface, then shows the hourglass for like 5 seconds. Yikes. The only time I ever had a slow startup earlier was if I had lots of mails coming in.

1. Checked hierarch.pm but that one only has 21 clean entries

2. 12 mails in my inbox, no way that could slow down things

3. Not too many filters, 16 simple ones, applied when the folder is opened

4. 6Mb down speed so the reason shouldn't be checking for new mail

5. Running off an SSD so not my HD either :)

6. Plenty of memory (8G), quad core etc

7. Closing and opening Pmail again has it opening instantly without the hourglass. But after a few minutes it's back to hourglassing.

So a bit stumped WHY the new version is *slow*. Since I like to open up my mail when *I* have time for it (i.e. not keeping it running in the background) 5 seconds is a nuisance. In addition to making me curious why... Tried to create some logs but I've forgot most about bug hunting in Pmail so I couldn't even find them. Uh, oh. Maybe better to listen if anyone has any ideas?

Been mailing here before as backgren or eskimo (IIRC) but had to create a new account because I changed provider and there went the old email address.

It looks like the Name_Unavailable entries re-appears quite in short time.. questions to developers why it appears/what is purpose/how to prevent it or hope it is possible to add e.g. an option how to clean it up automatically. Such slow speed openinning/rescan is really annoing.

Here is what is going on with the Name_unavailable entries in HIERARCH.PM.  When a mailbox is added to the folder list entries are added to the HIERARCH file.  When Pegasus is closed the HIERARCH file is updated with the current status of the folder structure.  If a connected mailbox is disconnected prior to closing Pegasus then Pegasus loses the folder name resulting in the Name_unavailable entries.  These entries contain the folder ID's from the connected mailbox so the next time that mailbox is connected these entries are used to display to folder structure as it was when the entries were created.  If you routinely add and disconnect mailboxes these Name_unavailable entries accumulate quickly.  My understanding is that they do not affect performance.  You could test this by closing Pegasus, renaming the HIERARCH.PM

---

Brian Fluet

Here is what is going on with the Name_unavailable entries in HIERARCH.PM.  When a mailbox is added to the folder list entries are added to the HIERARCH file.  When Pegasus is closed the HIERARCH file is updated with the current status of the folder structure.  If a connected mailbox is disconnected prior to closing Pegasus then Pegasus loses the folder name resulting in the Name_unavailable entries.  These entries contain the folder ID's from the connected mailbox so the next time that mailbox is connected these entries are used to display to folder structure as it was when the entries were created.  If you routinely add and disconnect mailboxes these Name_unavailable entries accumulate quickly.  My understanding is that they do not affect performance.  You could test this by creating a new HIERARCH.PM file and seeing if it makes a difference.  You can do this by closing Pegasus, renaming the HIERARCH.PM file then starting Pegasus.  I would be interested in the results of this test.  I have reduced a 117 KB HIERARCH to 1.9 KB without seeing a difference in performance but you might have a significantly larger HIERARCH file.  Rebuilding HIERARCH will flatten an folder structure so you may want to restore the original after the test then manually edit it if the test confirms a benefit to reducing its size.

---

Brian Fluet

I was wrong with that re-appearing of Name_Unavailable entries..... something else must be causing that slow opening of inbox messages: I checked my HIERARCH.PM file (about 38kbyte) and found no such entries - mail folder is on local drive and not connecting any other mboxes. Loading of Inbox with about 1000 messages takes minutes,  loading counter shows about 10messages per second... then tried to rename the HIERARCH.PM and - voila - inbox is loaded in no time, just some time spent maybe with creating new HIERARCH.PM file (the same size as before). So I simply reverted old file back, and noticed the same fast speed again (so for sure in my case delay is not caused by e.g. mail filtering rules)... the only change that has been caused is that last folder state (opened/closed etc) has been lost/reset to all closed state.

So I wonder if e.g. that info about folders state is the source of problem - maybe that info has been also re-created - I see about 5 files with fresh date/time that Pmail has touched/written to since that test...

After more than dozen years with Pmail, even I have been pushed to use Outlook and Google Mail and I see Pmail has  for me lot of clear advantages, even e.g. google mail is great for mobility and realtime search (and obviously also disadvantages - starting with fact messages are stored somewhere in cloud), I still prefer using Pmail... hope development will continue and such a legend will continue to satisfying it's fans.

You say 'Loading of Inbox with about 1000 messages takes minutes".  If by this you mean you have 1000 messages in your New mail folder than that is most likely the problem.  The rule of thumb is that around 750 messages Pegasus can no longer display new messages so if you have made it to 1000 you have done good. 

Pegasus was designed for unread mail to exist in the New mail folder with the Main folder being the working folder.  The flexibility of Pegasus allows for users to use the New mail folder as a working folder but there is a physical limit to how many messages can reside in the New mail folder before problems start occurring. 

 

---

Brian Fluet

myrabel,

Are you connecting to a host via an IMAP connection (hence the term "Inbox" vs. New mail folder)?  Your reference to a loading countdown indicates the opening of the New mail folder but your reference to "INBOX" could denote IMAP.  If an IMAP connection then my previous post is irrelevant.

---

Brian Fluet