After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 433782 - Optimise vCard folding
Optimise vCard folding
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Contacts
1.10.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: evolution-addressbook-maintainers
Evolution QA team
: 336574 442331 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-04-27 04:36 UTC by Øystein Gisnås
Modified: 2007-06-05 02:42 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18


Attachments
Suggested algorithm (applies to 1.10.1) (1.11 KB, patch)
2007-04-27 04:42 UTC, Øystein Gisnås
none Details | Review
Same patch with single iteration through string (1.03 KB, patch)
2007-05-01 22:18 UTC, Øystein Gisnås
none Details | Review
String buffer preallocated, line width=75 characters (201 bytes, patch)
2007-05-10 00:23 UTC, Øystein Gisnås
none Details | Review
String buffer preallocated, line width=75 characters, try again (1.92 KB, patch)
2007-05-10 05:50 UTC, Øystein Gisnås
accepted-commit_now Details | Review

Description Øystein Gisnås 2007-04-27 04:36:53 UTC
Please describe the problem:
It takes a very long time to add a large picture to a contact. The processor time is mostly spent on folding lines in e-vcard.c.

I've optimised the folding and created a patch. Please someone have a look at it, especially with regard to utf-8 correctness.

The speedup on my system is in the range 10x-100x. This problem is closely related to bug #312581, but is most easily tracked as separate bugs.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Øystein Gisnås 2007-04-27 04:42:44 UTC
Created attachment 87117 [details] [review]
Suggested algorithm (applies to 1.10.1)

Note that this algorithm folds the first line after 75 characters and the following lines at 73. This is probably not correct according to RFC-822. The current implementation works the same way, so it should be safe to continue doing that.
Comment 2 Srinivasa Ragavan 2007-04-28 17:18:19 UTC
Ross, you have any thoughts on this? 
Comment 3 Ross Burton 2007-04-30 16:47:44 UTC
Oh, nice patch.

It could be made even faster by manually looping over the string with g_utf8_next_char, because it will count 76 unicode characters twice per loop (once when calculating the length, and then again when getting the pointer).
Comment 4 Øystein Gisnås 2007-05-01 22:18:23 UTC
Created attachment 87366 [details] [review]
Same patch with single iteration through string

Like this? The code is a bit more unreadble, but should in theory be a bit quicker.

Choose whichever you like better..
Comment 5 Milan Crha 2007-05-07 11:26:20 UTC
I did a patch in bug #336574 in same part of code as this patch, but with other approach.
Comment 6 Øystein Gisnås 2007-05-08 21:38:01 UTC
There are 3 suggested patches now. I believe all of them work. For me the most important is that one of them is chosen and applied. I think Milan's patch is the quickest (but also the least maintainable code, probably). Ross, could you give thumbs up for one of them, or request further work if you have any suggestions for improvement?
Comment 7 Srinivasa Ragavan 2007-05-09 03:03:24 UTC
Great. I would prefer to push Milan's patch for 2.11.2 unless Ross has some more improvements that can be done along with this :)
Comment 8 Ross Burton 2007-05-09 20:14:52 UTC
Milan's patch looks good to me.  Preserving the exact output isn't really a great concern, and removing the variable line length might clean the code up a little.
Comment 9 Øystein Gisnås 2007-05-10 00:23:33 UTC
Created attachment 87923 [details] [review]
String buffer preallocated, line width=75 characters

Here's another go at the folding then. This time it's a simplified version of Milan's patch. It makes all lines 75 characters wide.

On my laptop, add_contact with 15 fields and a 250k photo takes roughly:
37s with current code
3s with my first patch
0,4s with Milan's patch
0,15s with this patch

Numbers for get_contact are more or less proportional.
Comment 10 Øystein Gisnås 2007-05-10 05:50:48 UTC
Created attachment 87931 [details] [review]
String buffer preallocated, line width=75 characters, try again
Comment 11 Srinivasa Ragavan 2007-05-11 04:21:33 UTC
Cool guys. Great patch. I will push the last one for 2.11.2. 

Ross: Does bug #312581 still hold good? or should we extend this work to that?
Comment 12 Ross Burton 2007-05-11 17:48:36 UTC
I think this patch should be committed, and then I'll re-sync the relevant changes in #312581 against latest svn.
Comment 13 Srinivasa Ragavan 2007-05-12 09:23:11 UTC
*** Bug 336574 has been marked as a duplicate of this bug. ***
Comment 14 Srinivasa Ragavan 2007-05-12 09:31:42 UTC
Please Commit this for head
Comment 15 Kjartan Maraas 2007-05-13 17:31:38 UTC
I commited this to trunk.
Comment 16 André Klapper 2007-06-05 02:42:55 UTC
*** Bug 442331 has been marked as a duplicate of this bug. ***