aboutsummaryrefslogtreecommitdiffstats
path: root/addressbook/ChangeLog
diff options
context:
space:
mode:
authorChris Toshok <toshok@ximian.com>2002-02-23 12:36:10 +0800
committerChris Toshok <toshok@src.gnome.org>2002-02-23 12:36:10 +0800
commit1755b16c23b6a7547f3b0135292937ec68661ad0 (patch)
tree6016924d48816f3007917d1ad9e53975cccd0089 /addressbook/ChangeLog
parentc1fa893c2a1a671cdcd84daf5ca1d0ff9fd233f4 (diff)
downloadgsoc2013-evolution-1755b16c23b6a7547f3b0135292937ec68661ad0.tar.gz
gsoc2013-evolution-1755b16c23b6a7547f3b0135292937ec68661ad0.tar.zst
gsoc2013-evolution-1755b16c23b6a7547f3b0135292937ec68661ad0.zip
[ Fixes bugs 20740, 16680, and god knows what else :) ] double the
2002-02-22 Chris Toshok <toshok@ximian.com> [ Fixes bugs 20740, 16680, and god knows what else :) ] * gui/widgets/e-addressbook-model.c (create_card): double the allocated size every time we need more space instead of using a fixed size increment. this helps huge queries. Also, remove the gtk_object_get of "file_as", as it was dead code. (book_view_loaded): handle errors here (by popping up a dialog). * backend/pas/pas-backend-ldap.c (view_destroy): search_idle -> search_timeout. (build_card_from_entry): comment out some spew, and unref ecard when we're done to plug a memory leak. (send_pending_adds): send along to the client all the cards we've been saving up. (poll_ldap): use a timeout for ldap_result to keep the backend from blocking (and it turns out keep the frontend from hanging waiting on a ref to complete) on large db's with few matches. Also, add some fairly smart, self-tuning aggregating of cards. Keep track of the number of cards we've sent the last time through as well as this time, and estimate the number we want to aggregate the next time based on them (we average them at the moment), subject to maximum/minimum number of cards. also, we have a maximum aggregation time, after which we force a flush if there are pending cards and recalculate our target pending number. there's a minimum wait time to possibly keep outselves from spamming the ui, although it's 0 at the moment. Lastly, make sure to only notify the GUI of status messages when we need to. this results in a *huge* savings. (ldap_search_handler): initialize all the pending card stuff, and use a timeout instead of an idle function for poll_ldap. * backend/ebook/e-book-view-listener.c (e_book_view_listener_queue_response): performance optimization for large adds. If we're a CardAddedEvent and there's an existing CardAddedEvent at the end of the queue, just concat the lists of cards together. This is to keep the gui from falling further and further behind the ldap backend, which is merrily spewing updates at the gui. svn path=/trunk/; revision=15807
Diffstat (limited to 'addressbook/ChangeLog')
-rw-r--r--addressbook/ChangeLog42
1 files changed, 42 insertions, 0 deletions
diff --git a/addressbook/ChangeLog b/addressbook/ChangeLog
index a46e0b2448..e144519c4e 100644
--- a/addressbook/ChangeLog
+++ b/addressbook/ChangeLog
@@ -1,3 +1,45 @@
+2002-02-22 Chris Toshok <toshok@ximian.com>
+
+ [ Fixes bugs 20740, 16680, and god knows what else :) ]
+ * gui/widgets/e-addressbook-model.c (create_card): double the
+ allocated size every time we need more space instead of using a
+ fixed size increment. this helps huge queries. Also, remove the
+ gtk_object_get of "file_as", as it was dead code.
+ (book_view_loaded): handle errors here (by popping up a dialog).
+
+ * backend/pas/pas-backend-ldap.c (view_destroy): search_idle ->
+ search_timeout.
+ (build_card_from_entry): comment out some spew, and unref ecard
+ when we're done to plug a memory leak.
+ (send_pending_adds): send along to the client all the cards we've
+ been saving up.
+ (poll_ldap): use a timeout for ldap_result to keep the backend
+ from blocking (and it turns out keep the frontend from hanging
+ waiting on a ref to complete) on large db's with few matches.
+
+ Also, add some fairly smart, self-tuning aggregating of cards.
+ Keep track of the number of cards we've sent the last time through
+ as well as this time, and estimate the number we want to aggregate
+ the next time based on them (we average them at the moment),
+ subject to maximum/minimum number of cards. also, we have a
+ maximum aggregation time, after which we force a flush if there
+ are pending cards and recalculate our target pending number.
+ there's a minimum wait time to possibly keep outselves from
+ spamming the ui, although it's 0 at the moment.
+
+ Lastly, make sure to only notify the GUI of status messages when
+ we need to. this results in a *huge* savings.
+ (ldap_search_handler): initialize all the pending card stuff, and
+ use a timeout instead of an idle function for poll_ldap.
+
+ * backend/ebook/e-book-view-listener.c
+ (e_book_view_listener_queue_response): performance optimization
+ for large adds. If we're a CardAddedEvent and there's an existing
+ CardAddedEvent at the end of the queue, just concat the lists of
+ cards together. This is to keep the gui from falling further and
+ further behind the ldap backend, which is merrily spewing updates
+ at the gui.
+
2002-02-21 Ettore Perazzoli <ettore@ximian.com>
* gui/component/Makefile.am: Define $(iconsdir).