couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: RIP Temp Views?
Date Wed, 15 Jul 2009 16:41:04 GMT
Hi Kowsik,

Thanks for your feedback :)

On 15 Jul 2009, at 18:29, kowsik wrote:

> I like temp views. It was how I got started with couch as it was easy
> to experiment with the knowledge that it was going to be slow for
> large documents. It's possible in Futon to have a warning message (big
> bold blinking red font) that indicates that this is for
> experimentation and not for production use. Part of the problem is
> Futon UI doesn't tell the user about temp views.

As I said in my original, Futon wouldn't change.


> On a related note, why not spend more dev cycles parallelizing the
> view server to harness multiple cores to the point even the temp views
> scale better?

It still gives users the wrong idea about views I've seen this too many
times now:

function(doc) {
   if(doc.value == 415) {
     emit(doc._id, doc);
   }
}

On top of that, when optimized (see below) I hope we get to the point
where view building is I/O, not CPU bound. parallelizing wouldn't buy
us anything (not saying single node parallel execution doesn't make
sense, but right now, it makes little sense).


> I've been on this forum for a while now and until Brian
> recently published some concrete performance benchmarks there really
> haven't been much discussions (that I'm aware of) about raw couchdb
> view server speed (using chrome, tracemonkey, etc).

Speed improvements are being talked about. JS execution speed is
not yet showing up in any profiles (tests with V8/tracemonkey didn't
show significant improvements as a consequence). The biggest
contenders for speed improvements are native Erlang views
js-to-erl anyone? And native JSON parsing on both ends of the
view server (eep0018 and native JSON.pare()).


> As we are just approaching 0.10, I do understand that need to focus on
> replication, couch apps, ease of use, RESTful-ness and all the rest,
> while the "core" part (IMHO) has somewhat been deprioritized. This is
> just my observation based on the threads of discussion here.

This is a point separate from the discussion about temp views. The
core has seen many improvements (tail append headers, soon:
deterministic revs, etc.). If you want to bring up the point that we
should shift priorities, can you please open a new thread?

Thanks again for your feedback!

Cheers
Jan
--



>
> 2 cents,
>
> K.
>
> On Wed, Jul 15, 2009 at 9:19 AM, Nicholas  
> Orr<nicholas.orr@zxgen.net> wrote:
>> On Thu, Jul 16, 2009 at 1:57 AM, Jan Lehnardt <jan@apache.org> wrote:
>>
>>>
>>> If you like temp views, I'd like to take your concerns into  
>>> consideration.
>>
>>
>> I like temp view for figuring stuff out.
>> I'm not at the stage where I can have thought and presto perfect  
>> map/reduce
>> materialises on the screen in a few keystrokes.I usually only have  
>> 10 max
>> documents in the db.
>> So have never run into the performance issues.
>>
>> After I've figured stuff out I create a proper view.
>> Then proceed to fill up the database
>>
>> Since I now use ruby for views its not going to be much use to me  
>> having a
>> js temp view emulator...
>> I like ruby syntax, its nice: emit(key,val) unless doc.name.nil?
>>
>> Guess when you get rid of temp views "as is" it'll just take a bit  
>> longer to
>> "try" stuff.
>>
>> Nick :)
>>
>


Mime
View raw message