Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <0C4127A6-0749-4535-98B1-9F28EACBA1B8@apache.org>
From: Jan Lehnardt <jan@apache.org>
To: dev@couchdb.apache.org
In-Reply-To: <7db9abd30907150929q592e999avb0daa3fdc82a21f0@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: RIP Temp Views?
Date: Wed, 15 Jul 2009 18:41:04 +0200
References: <467DF120-D9E6-4D43-99B0-E643605555C3@apache.org>
 <55047b710907150919t435ce716q438a502be0188aec@mail.gmail.com>
 <7db9abd30907150929q592e999avb0daa3fdc82a21f0@mail.gmail.com>

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 :)
>>
>