incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manuel de la Peña <eti...@gmail.com>
Subject Re: Ars Technica finds DesktopCouch too laggy
Date Fri, 14 May 2010 14:25:50 GMT
On 14 May 2010 10:00, Eric Casteleijn <eric.casteleijn@canonical.com> wrote:

> On 05/14/2010 08:43 AM, Wout Mertens wrote:
>
>> Hi group,
>>
>> I noticed with sadness the rather disappointing review of the DesktopCouch
>> feature of Ubuntu at Ars Technica:
>>
>>
>> http://arstechnica.com/open-source/reviews/2010/05/lucid-dream-ars-reviews-ubuntu-1004.ars/9
>>
>> "The take-away point is that the amount of latency and CPU overhead that
>> DesktopCouch introduces is just not conducive to building responsive desktop
>> applications that run on a wide range of ordinary consumer hardware. In
>> cases where the number of records is in the tens of thousands, it's more
>> sensible to use SQLite and use DesktopCouch only for the parts that need to
>> be synchronized."
>>
>> I wonder where the lag is introduced. DesktopCouch is, as I understand it,
>> a Python API for storing and synchronizing user data like settings and chat
>> logs, using CouchDB as the backend.
>>
>
> That is correct: it's built on top of python-couchdb and is meant as a
> library that allows users to synchronize structured data between their
> machines and with a cloud, as well as allowing different applications to use
> the same backend for the same kind of data. (So for instance storing
> contacts from evolution in couch, and then having them accessible from any
> other application that is interested in contacts.)
>
>
>  Is CouchDB too slow to use on a desktop system as a desktop database?
>>
>
> By no means: I don't think any of the issues the gwibber developers have
> run into are necessarily CouchDB problems.
>
> I think it's a mixture of a relatively young and fluid API (desktopcouch),
> and some places where Gwibber could have optimized their usage of
> desktopcouch/couchdb: right now it adds every incoming twitter/
> identi.ca/facebook message to the db one by one as it arrives, and
> immediately requeries the view. If you follow a lot of people, or worse,
> have a search stream open, this means the views are continually being
> rebuilt, and you never get the speed benefit of a prebuilt view.
>
> It would help if incoming messages were added in bulk every x seconds, and
> the views only queried once per minute or so. Personally, I've not had
> issues with gwibber in quite a while. I think a lot of the issues in
> desktopcouch (and some in Gwibber itself) have been found and ironed out.
>
> --
> eric casteleijn
> https://code.launchpad.net/~thisfred
> Canonical Ltd.
>
> Eric,

I think the problem with gwibber is the fact that they are using
desktopcouch and therefore CouchDB wrongly. The fact that messages are
retrieved from the REST APIs of the social medias, transformed into gwibber
understandable records, pushed into couchDB and later retrieved is probably
THE problem. Every time they do that, the index of the views have to be
updated. The whole process does not make bloody sense since
they already have the data in memory, why would they push it in the db and
read it afterwards???

Immediate push and pull from the db does not make any sense and it is a
terrible algorithm. Knowing this you can decide whose "fault" it is.... To
be honest, last time I jump off a building and broke my legs I blamed
gravity, that heartless b****! it should stop working with
I jump through the widow!!

Mandel

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message