[Adium-devl] ByObject prefs suck

[Colin Barrett]

I kinda responded to that in the email I just sent, but it's important  
enough to say again: profiling data is needed to figure out if this is  
a bottleneck.

The read penalty for a plist can be pretty heavy as it grows. But  
getting message history out of there should keep pref sizes more  
manageable.

The one thing I would like to see is a mechanism for cleaning out old  
values for keys that are no longer used.

-Colin

On Dec 6, 2006, at 4:46 PM, disposable at infinitenexus.com wrote:

> Wouldn't converting to a db-backed system add the inherent overhead  
> of the dbms? As is we only incur read/write penalties and it might  
> not look pretty [and needs some cleanup, as is being discussed.] In  
> addition, as David alluded to, adding new values requires schema  
> migration and checking, which is more overhead and maintenance. A  
> final caveat - we have to either choose the lowest common  
> denominator [i.e., whatever is present on all systems, guaranteed]  
> or we bulk our binary size with another component.
>
> Those notes aside - Colin, could you please articulate how exactly  
> such a move is a windfall versus the costs associated with it?
>
> - brian 'bgannin' ganninger
>
>
> On Dec 6, 2006, at 5:57 PM, Colin Barrett wrote:
>
>> On Dec 6, 2006, at 1:10 PM, Augie Fackler wrote:
>>
>>> [disclaimer: this is my reading day between classes and finals, and
>>> my email ended up being a weird stream-of-consciousness event.
>>> Continue at your own mental health risk.]
>>> While trying to track down a weird bug today, I noticed my ByObject
>>> prefs were freaking huge: 2,030 or so ByObject prefs for *just*
>>> contacts, not including groups (including metas though).
>>> I nuked all non-group ByObject files and let them regenerate, and  
>>> now
>>> the folder has 288 items in it, of which 23 are groups.
>>> Clearly, we're storing ByObject prefs we just flat out don't need.
>>> So what I'd like to do is figure out what the ByObject prefs are
>>> storing for each contact, and attempt to find ways to store the
>>> important data in something that's not ByObject so we could make
>>> ByObject files be deleted if they're no longer needed.
>>> What I've figured is in there now is:
>>> 1) Preferred account
>>> 2) Spelling Language
>>> 3) Events
>>> 4) Local alias (?)
>>> 5) Old message history
>>>
>>> 5 can just be forgotten about with XML logging. I think we already
>>> don't use 4, but I want to be sure. 2 is definitely something we
>>> should save, as are preferred account and events.
>>> That said, I think it might make more sense to store one large file
>>> rather than lots of little files, since we're looking at about 2k
>>> files with an average size of .5 kb, that's about 6 wasted megs of
>>> disk space for a bunch of files that themselves shouldn't take more
>>> than 1 meg.
>>
>> SQLite and/or CoreData and/or BerkelyDB and/or something other than
>> plists would be perfect for this. Aside from using text files, what  
>> we
>> have now is a pretty terrible way of doing it, so pretty much  
>> anything
>> would be an improvement.
>>
>>> Events I think it might make sense to store in a dedicated events
>>> preference location - and then include a more complete events editor
>>> that lets you see all of the configured events (sound notifs,
>>> everything) so that events for no-longer-listed buddies can be
>>> deleted (for example, custom sounds for a particular buddy) - or at
>>> least more easily purged.
>>
>> This would be awesome. Our events interface is already a bit
>> overwhelming though, so we would need to be quite careful when
>> designing it. Our current one could use a lot of work.
>>
>>> I don't really see a need to store special events for unbuddied
>>> people anyway, so maybe it'd make more sense to just nuke events
>>> associated with a particular ListObject when that ListObject is
>>> deleted? Maybe we could do that with writing direction and last used
>>> spelling language too? Preferred account?
>>
>> What about for people who aren't on your list, but you still want to
>> do send later for? That's powered by the Events system.
>>
>> -Colin
>>
>> _______________________________________________
>> Adium-devl mailing list
>> Adium-devl at adiumx.com
>> http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com
>>
>
> _______________________________________________
> Adium-devl mailing list
> Adium-devl at adiumx.com
> http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com