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<[email protected]> wrote:
On Thu, Jul 16, 2009 at 1:57 AM, Jan Lehnardt <[email protected]> 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 :)
