[Evolution-hackers] Some brainstorming about CamelMessageContentInfo

[Philip Van Hoof <spam pvanhoof be>]

About my tone: this is a brainstorming tone and E-mail.

I'm questioning things. I am NOT trying to illustrate some people are
idiots.

I grew up with the idea that hackers and coders constantly question
things and yes, also each other. Question question question .. question
everything. Always question everything.

My intention here is to help you guys find the memory of Evolution. I'm
not trying to present myself als the person who's almighty good at
finding memory problems. I simply question a lot and keep kicking and
trying things until I find it. Valgrind is just a tool, my questioning
is my true technique.

I use the brainstorming tone and I'm questioning whether my conclusions
and ideas make sense. I'm not trying to contest people or telling them
my solution is the fucking best of the world. That's not the point.

I hope after a few days/weeks people here will understand my methodology
when I do this type of E-mails. Because I think a lot of the problems
with past discussions where simply based on wrong conclusions and errors
in the communication itself. We don't have our body language here. I
miss it, because I would use that a lot on you guys.


This is the CamelMessageContentInfo struct. 

struct _CamelMessageContentInfo {
   struct _CamelMessageContentInfo *next;

   struct _CamelMessageContentInfo *childs;
   struct _CamelMessageContentInfo *parent;

   CamelContentType *type;
   char *id;
   char *description;
   char *encoding; /* this should be an enum?? */
   guint32 size;
};

With

typedef struct {
        char *type;
        char *subtype;
        struct _camel_header_param *params;
        unsigned int refcount;
} CamelContentType;


If your provider sets "build_content" of the CamelFolderSummary to TRUE,
camel it will create an instance of this struct for all your headers.

It looks like the IMAP provider of Camel does this. Which is fine, of
course. If there's also actually something interesting in it.

It seems that only the "type" pointer is usefully filled in after
checking for now 46,000 headers in my IMAP folders.

The id, description and encoding are for all these 46k headers is set to
NULL.

Not THAT bad, you might think? :-) There's plenty of memory!

Except for the fact that each pointer on a x86 consumes four bytes. Let
us calculate!

4 bytes * 3 pointers * 46,000 headers equals 552,000 bytes or 539kb.

I have a few folders that are sized 20,000 headers. For each such
header, there's 12 bytes wasted in NULL's. Who here has counted all the
headers his Evolution *can* show in his current session? Multiply that
with 12 and divide that with 1024*1024, that is how much megabytes your
Evolution is consuming for just this.

I have a mobile phone that has FAR less memory then my Evolution
currently has NULL pointers ;-)


This would slightly improve this situation (and don't allocate extra if
there's nothing interesting in id, description and encoding).

struct _CamelMessageContentInfo {

  struct _CamelMessageContentInfo *next;
  struct _CamelMessageContentInfo *childs;

  CamelContentType *type;
  CamelMessageContentInfoExtra *extra;
  guint32 size;
};

struct _CamelMessageContentInfoExtra {
  char *id;
  char *description;
  char *encoding; /* this should be an enum?? */
};


Or what about this? Because CamelContentType are also 3 pointers and an
int on top of it. The type and subtype could be done using a mechanism
like the camel_pstring_add.

struct _CamelMessageContentInfo {

  struct _CamelMessageContentInfo *next;
  struct _CamelMessageContentInfo *childs;

  char *type, *subtype;
  CamelMessageContentInfoExtra *extra;
  guint32 size;
};

struct _CamelMessageContentInfoExtra {
  char *id;
  char *description;
  char *encoding; /* this should be an enum?? */
};



-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be