Hello
When Mbox Split feature was not implemented, I wrote a code and comparing it with your new 24.6 split method, yours seems to be about 10 times slower!
May I share my code so you kindly pass it to the devs. might be useful and they can update the method to be faster?
Just it’s in VB 
Thanks.
Hello,
Yes, please, you can share your code example.
Thanks.
1 Like
Hello,
I’ve got my temp license to fully test the situation and found that the performance problem is from the new build itself, no matter if I use my code or your method.
Until version 24.2 it was OK, but version 24.3 and onward has a huge performance degradation, when using Mbox reader and writer to split.
Hopefully you have the internal history of your code releases, so can check what happened between 24.2 and 24.3.
An important symptom is that reading and writing Mbox was a smooth process until 24.2.
But since 24.3 it’s not consistent in speed and will have occasional pauses during the process.
Perhaps extra internal processes were added which are expensive to run.
Hello,
We have opened the new investigation ticket in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): EMAILNET-41383
Thank you.
Hi
To save your reproduction time, please test my project with 24.2 and 24.3/24.6 and kindly confirm the issue.
Best.
MboxTest.zip (3.9 MB)
Hello, Thank you.
1 Like
Hello,
Sorry if it’s too early to check but am worried sick about this issue, were you able to reproduce it?
It has come to my attention that when saving all items in Ost PersonalStorage using the same code base but with different Aspose dlls, also the new build is slower is reading Ost PersonalStorage, about 50% performance (speed) degradation.
Olm extraction, about 5 times slower!
Nsf extraction, about 8 times slower!
Tgz extraction, not much but still some!
Thanks for your kind attention 
Could you please provide detailed code examples for each case (OST, NSF, OLM, TGZ)?
Additionally, share the environment parameters you’re testing in (version of .NET, version of Visual Studio), and the library version number from which you started noticing these issues.
1 Like
Sure, will create ready to run samples so you can instantly see, just a bit of time needed.
For now, can you please confirm if you were able to reproduce the Mbox issue I’ve sent?
And one thing I already shared, when extracting Tgz storage:
TgzReader.GetTotalItemsCount returns the total number of items inside, correct, but reading all items inside it using the below code will not return contacts, so cannot export them.
We can use TgzReader.ExportTo but this method does not support any events to show the progress, to reflect the number/type of the item being processed, and a .Cancel property to cancel the process!
Is this accepted to implement?
Thanks
While TgzReader.ReadNextMessage
Hello.
mbox problem has been confirmed.
Since TGZ is a compressed archive format, the TgzReader was originally designed solely for extracting data from the archive.
The TGZ Zimbra format is not widely used, so there is no significant need to prioritize and invest efforts in redesigning the implementation, unless it is for paid support.
However, there are tickets for its additional implementation.
1 Like
Thank you very much for confirmation, will share the new samples soon.
Well, I am fine with using Aspose Zip to extract Tgz files, but it will only extract file as is, can you make the internal .meta file parser used in Zimbra class visible so we can use it to convert such .meta files to the appropriate format?
ie under Emailed Contacts folder: admin.meta
{"date":1562075807,"Path":"/Emailed Contacts/","metadata":"d3:fldd5:email20:admin@zimbratest.com9:firstName5:admin8:fullName5:admine1:vi10ee","Ver":10,"mod_metadata":7863,"FlagStr":"","volume_id":0,"unread":0,"change_date":1562075807,"mod_content":7863,"flags":0,"TagStr":"","type":6,"size":0,"sender":"admin","TagNames":"","parent_id":-1,"id":263,"folder_id":13,"index_id":0,"imap_id":263}
Internally you convert it to vcf, make those methods visible maybe?
.meta parsing is not fully implemented. In addition to contacts, there are also tasks, calendars. In addition, we need to implement a new enumerator that will return all types of items.
1 Like
Hello,
When saving a MapiContact Msg as Eml, is this known and has a workaround?
contact.jpg (176.6 KB)
Thanks
To reproduce, just extract and run this sample with the included v23 dll and copy the resulting contact.eml to somewhere else.
Now, replace the Aspose Email dll with the latest .net 4.0 build and run again.
Compare 2 contact.eml files, thanks
ContactTest.zip (3.9 MB)
The original MSG contact contains a body in RTF format. When converting to EML and MHT, we keep the RTF as is (as per your previous request). However, EML does not support RTF, and therefore Outlook displays the RTF as raw text. To preserve both the content and the display in Outlook, use TNEF when converting and saving to EML. TNEF is intended for this purpose.
ConvertAsTnef = true in MailConversionOptions
FileCompatibilityMode = FileCompatibilityMode.PreserveTnefAttachments in EmlSaveOptions
NOTE: as mentioned earlier, do not write regarding MapiContact in this thread. This thread discusses different issue. Create a new topic with a new title.
Hello
About the performance / speed issue when saving Ost / Pst files, here’s the project, steps to reproduce:
-
Copy a sample Ost file ( better to be larger than 50 mb ) to this path:
OstTest\bin\Release
named:
ost.ost -
Run the test app and note the total time shown at the end.
-
Close Visual Studio, replace Aspose.Email.dll with the latest build 24.6 for .net 4.0 full, open the project again and re-build all, run the project again and compare the total time.
Thanks.
OstTest.zip (3.8 MB)
Thanks, I have added it to the ticket.
1 Like
Thanks, just please confirm the issue once tested, and about the olm, can you please do the same test with v23 against v24?
Hello,
Ok, sure.
1 Like
Thanks, and sorry for the inconvenience