[Evolution-hackers] Handy GObject debugging trick

2011-03-09 Thread Matthew Barnes
Long ago and cubicle far, far away I wrote this little debugging
enhancement for GObject that collects statistics about instance
creation, destruction, etc. by class type and then prints a nicely
formatted report when piped through a tool named 'gobject-stats'.

My proposal for it got kinda hijacked and veered off into something even
fancier involving systemtap (it all kinda went over my head), so I don't
expect my patch to ever actually land in upstream GLib.

Nevertheless, I had occasion to wish for this feature again recently so
I dusted off my original patch and rebased it for GLib 2.28.

Here's the link (comment #46):
https://bugzilla.gnome.org/show_bug.cgi?id=354457#c45

Thought others might find it handy so I'm mentioning it.


How to use it:

1. Build GLib with debugging features enabled (--enable-debug).
   Unstable GLib releases turn debugging features on by default,
   stable releases turn debugging features off by default.

2. GOBJECT_DEBUG=types $MY_APPLICATION 21 | gobject-stats

3. Do stuff in $MY_APPLICATION, then quit.

4. Read the stats to see how badly $MY_APPLICATION is leaking objects.


Here's a sample run I did on e-calendar-factory 2.91.92:

$ GOBJECT_DEBUG=types e-calendar-factory 21 | gobject-stats

Instance Type   Max Population  # Created  # Destroyed  # 
Leaked
--  --  -  ---  

GParamBoolean   35 350  
  35
EGdbusCalViewStub   30 300  
  30
GParamObject27 270  
  27
GParamString22 220  
  22
ECalBackendSExp 21 39   23  
  16
GParamEnum  16 160  
  16
ESourceGroup16 164  
  12
GParamPointer   11 110  
  11
GParamUInt  11 110  
  11
GParamBoxed 10 100  
  10
ESource 16 16   10  
   6
EDataServerModule6  60  
   6
GParamInt6  60  
   6
GParamFlags  5  50  
   5
ESourceList  4  41  
   3
GParamULong  3  30  
   3
GParamGType  2  20  
   2
GSimpleAsyncResult   7675  674  
   1
GDBusMessage 4452  451  
   1
GSocket  2 13   12  
   1
GCancellable 2  87  
   1
GDBusAuth1  21  
   1
GDBusConnection  1  21  
   1
GIOPConnection   2  21  
   1
GSocketInputStream   1  21  
   1
GSocketOutputStream  1  21  
   1
GUnixConnection  1  21  
   1
GUnixSocketAddress   1  21  
   1
ECalBackendCalDAVEventsFactory   1  10  
   1
ECalBackendCalDAVMemosFactory1  10  
   1
ECalBackendCalDAVTodosFactory1  10  
   1
ECalBackendContactsEventsFactory 1  10  
   1
ECalBackendFileEventsFactory 1  10  
   1
ECalBackendFileJournalFactory1  10  
   1
ECalBackendFileTodosFactory  1  10  
   1
ECalBackendGroupwiseEventsFactory1  10  
   1
ECalBackendGroupwiseJournalFactory   1  10  
   1
ECalBackendGroupwiseTodosFactory 1  10  
   1
ECalBackendHttpEventsFactory 1  10  
   1
ECalBackendHttpMemosFactory  1  10  
   1
ECalBackendHttpTodosFactory  1  10  
   1
ECalBackendWeatherEventsFactory  1  

[Evolution-hackers] Sqlite cache for address-book storage in EDS

2011-03-09 Thread Chenthill Palanisamy
Hi,
   I was going through the Address-book cache used in EDS while starting to
write the address-book backend for EWS. We use EBookBackendCache that stores
in the form of xml, EBookBackendDBCache which uses libdb for storing the
VCard strings. While EBookBackendSummary stores the information about names,
email ids for faster lookup.

Some backends use EBookBackendCache and some use EBookBackendDBCache.

ldap, google, webdave uses EBookBackendCache.
file, groupwise, exchange uses EBookBackendDBCache.

I was wondering if its worth writing a EBookBackendSqliteCache as we are
already using sqlite for string emails and later migrating all backends to
use the same.  The summary and VCard strings can be stored in a single Cache
without the need for using EBookBackendSummary. Any thoughts ?

- Chenthill.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Sqlite cache for address-book storage in EDS

2011-03-09 Thread Milan Crha
On Thu, 2011-03-10 at 12:09 +0530, Chenthill Palanisamy wrote:
 file, groupwise, exchange uses EBookBackendDBCache.

Hi,
do not forget that the DB cache is compiled conditionally, because some
distros do not ship libdb. Using SQLite for this was mentioned months
ago, only no-one got time to actually do it, so go for it.

Only think of two things:
- using binary storage for this kind of data is bad for cases where
  the binary file breaks, either due to an update/downgrade of the
  library providing access to it, or just by a crash. It's not so hot
  with camel as SQLite has there only summary data, but if you want to
  store also real data in it, then it can be a problem. There are people
  having issues recovering their data from addressbook storage already,
  but if you are going to do any change on it, then it would be good to
  think of that from the beginning. It would be good to store raw vCards
  in some plain text file(s) which will be indexed by SQLite summary.
  This plain text file(s) will be then easy to import to evolution if
  something goes wrong, and with erasing SQLite file user will not
  loose any valuable data. (I'm thinking of a flat maildir approach
  here.)

- be able to store custom values in the summary - backends can have
  a need to make its own notes in the summary, so make it possible for
  it. As these might not be so critical as contact information itself,
  then it should be fine to store to summary only.
Bye,
Milan

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers