On Sunday, August 18, 2013, Jason Smith wrote:
Nine times faster than O(n) is still O(n).
If people take this on, I will be your biggest cheerleader. My point is to
ask what problem this solves. After some thought I think it does NOT solve
a technical problem, it solves a perception and
On Sun, Aug 18, 2013 at 1:08 PM, Benoit Chesneau bchesn...@gmail.comwrote:
On Sunday, August 18, 2013, Jason Smith wrote:
Nine times faster than O(n) is still O(n).
If people take this on, I will be your biggest cheerleader. My point is
to
ask what problem this solves. After some
On Sun, Aug 18, 2013 at 6:51 AM, Thanos Vassilakis than...@gmail.comwrote:
Build views performance gains:
Python 4-6 times faster + less memory
Whatever the results of this benchmark are, this not the first time, I
heard that the python engine is faster than the Javascript one. I wonder
what
On Sun, Aug 18, 2013 at 10:29 AM, Benoit Chesneau bchesn...@gmail.com wrote:
On Sun, Aug 18, 2013 at 6:51 AM, Thanos Vassilakis than...@gmail.comwrote:
Build views performance gains:
Python 4-6 times faster + less memory
Whatever the results of this benchmark are, this not the first time, I
FWIW: this thread has been the best holy war I've read in a long time.
:-)
On Aug 17, 2013, at 11:51 PM, Alexander Shorin kxe...@gmail.com wrote:
On Sun, Aug 18, 2013 at 10:29 AM, Benoit Chesneau bchesn...@gmail.com wrote:
On Sun, Aug 18, 2013 at 6:51 AM, Thanos Vassilakis
I agree! At least, assuming you are speaking frankly and not sarcastically.
This is a great moment in the CouchDB community. Lots of viewpoints. Lots
of different experience and expertise. Lots of discussion, all of it civil
and respectful. It was positive for me, I just flat-out changed my mind
At 11:49 16/08/2013, Volker Mische wrote:
What if we split document metadata from document itself? E.g. pass
_id, _rev and other system or meta fields with separate object. Their
size much lesser than whole document, so it will be possible to fast
decode this metadata and decide is doc need
Build views performance gains:
Python 4-6 times faster + less memory
Erlang 7-9 times faster + much less memory.
On Aug 16, 2013, at 18:54, Jan Lehnardt j...@apache.org wrote:
I think it is worth putting Jason’s and Jens’s viewpoints on a scale of
“learning to live with the pain” and
Nine times faster than O(n) is still O(n).
If people take this on, I will be your biggest cheerleader. My point is to
ask what problem this solves. After some thought I think it does NOT solve
a technical problem, it solves a perception and adoption problem.
The problem a 9x speed up solves is,
On 08/15/2013 11:53 AM, Benoit Chesneau wrote:
On Thu, Aug 15, 2013 at 11:38 AM, Jan Lehnardt j...@apache.org wrote:
On Aug 15, 2013, at 10:09 , Robert Newson rnew...@apache.org wrote:
A big +1 to Jason's clarification of erlang vs native. CouchDB
could have shipped an erlang view server
On Fri, Aug 16, 2013 at 11:05 AM, Volker Mische volker.mis...@gmail.comwrote:
On 08/15/2013 11:53 AM, Benoit Chesneau wrote:
On Thu, Aug 15, 2013 at 11:38 AM, Jan Lehnardt j...@apache.org wrote:
On Aug 15, 2013, at 10:09 , Robert Newson rnew...@apache.org wrote:
A big +1 to Jason's
On Fri, Aug 16, 2013 at 1:12 PM, Benoit Chesneau bchesn...@gmail.com wrote:
I agree, (modulo the fact that I would replace a string by a binary ;) but
that would be only possible if we extract the metadata (_id, _rev) from the
JSON so couchdb wouldn't have to decode the JSON to get them.
On 08/16/2013 11:32 AM, Alexander Shorin wrote:
On Fri, Aug 16, 2013 at 1:12 PM, Benoit Chesneau bchesn...@gmail.com wrote:
I agree, (modulo the fact that I would replace a string by a binary ;) but
that would be only possible if we extract the metadata (_id, _rev) from the
JSON so couchdb
On Aug 15, 2013, at 10:14 AM, Jason Smith j...@apache.org wrote:
To restate my final sentence which you quoted: Accessing a view is an index
scan, it hardly matters what the total data size is; therefore after the
building period, all views are basically always instantly available.
You’re
On Fri, Aug 16, 2013 at 10:16 PM, Jens Alfke j...@couchbase.com wrote:
On Aug 15, 2013, at 10:14 AM, Jason Smith j...@apache.org wrote:
To restate my final sentence which you quoted: Accessing a view is an
index
scan, it hardly matters what the total data size is; therefore after the
I think it is worth putting Jason’s and Jens’s viewpoints on a scale of
“learning to live with the pain” and “finding relief for the pain”, where
“pain” is any of View Build Time or View Index Time from Jason’s glossary.
If living with the pain works for you, Jason’s point of view is very
On Thursday, August 15, 2013, Andrey Kuprianov wrote:
Doesnt server performance downgrade, while views are being rebuilt? So the
faster they are rebuilt, the better for you.
If my view build would degrade total performance to cross an unacceptable
threshold, then I am really riding the line!
Oh, also:
They are **not** Erlang views. They are **native** views. We should
emphasize the latter to remind ourselves about the security and reliability
risks which Bob identifies.
They are very powerful, but it is a trade-off. Once I had a customer who
had a basic class document describing
WaitI'm a tad confused here..Jason what is the difference between
native views and Erlang views?...
On Aug 14, 2013 11:16 PM, Jason Smith j...@apache.org wrote:
Oh, also:
They are **not** Erlang views. They are **native** views. We should
emphasize the latter to remind ourselves about the
To me, an Erlang view is a view server which supports map, reduce, show,
update, list, etc. functions in the Erlang language. (Basically it is
implemented in Erlang.)
A view server is a subprocess that runs beneath CouchDB which communicates
with it over standard i/o. It is a different process in
Whoa...OK...that I had no idea about...thanks for taking the time to go to
that granularity, by the way.
So does this mean that the process memory is shared? As apposed to living
in its own space?.so if someone accumulates a large json object in a list
function its chewing up couchdb's memory?...
Yes, to a first approximation, with a native view, CouchDB is basically
running eval() on your code. In my example, I took advantage of this to
build a nonstandard response to satisfy an application. (Instead of a 404,
we sent a designated fallback document body.)
But, if you accumulate the list
A big +1 to Jason's clarification of erlang vs native. CouchDB
could have shipped an erlang view server that worked in a separate
process and had the stdio overhead, to combine the slowness of the
protocol with the obtuseness of erlang. ;)
Evaluating Javascript within the erlang VM process
On Aug 15, 2013, at 10:09 , Robert Newson rnew...@apache.org wrote:
A big +1 to Jason's clarification of erlang vs native. CouchDB
could have shipped an erlang view server that worked in a separate
process and had the stdio overhead, to combine the slowness of the
protocol with the
On Thu, Aug 15, 2013 at 11:38 AM, Jan Lehnardt j...@apache.org wrote:
On Aug 15, 2013, at 10:09 , Robert Newson rnew...@apache.org wrote:
A big +1 to Jason's clarification of erlang vs native. CouchDB
could have shipped an erlang view server that worked in a separate
process and had the
On Aug 15, 2013, at 11:53 , Benoit Chesneau bchesn...@gmail.com wrote:
On Thu, Aug 15, 2013 at 11:38 AM, Jan Lehnardt j...@apache.org wrote:
On Aug 15, 2013, at 10:09 , Robert Newson rnew...@apache.org wrote:
A big +1 to Jason's clarification of erlang vs native. CouchDB
could have
On Aug 15, 2013, at 1:09 AM, Robert Newson rnew...@apache.org wrote:
Off the top of my head, I don't know a safe
way to evaluate JS in the VM. A NIF-based approach would either be
quite elaborate or would trip all the scheduling problems that
long-running NIF's are now notorious for.
Yeah,
Sorry if this is beating a dead horse.
On Thu, Aug 15, 2013 at 11:37 AM, Jens Alfke j...@couchbase.com wrote:
On Aug 14, 2013, at 8:52 PM, Jason Smith j...@apache.org wrote:
View building time feels important during development but it is
irrelevant
during operation. Production servers
I'm curious... What exactly is the performance gain from writing
views/shows/ etc in Erlang vs JavaScript... From what I've seen the
JavaScript view server is sufficiently fast and feature complete.
So my question is this Is the Erlang view server that much faster?...
Is there another gain
background. You can
measure it with you functions and data and share with us (:
--
,,,^..^,,,
On Wed, Aug 14, 2013 at 8:54 PM, Stanley Iriele siriele...@gmail.com wrote:
I'm curious... What exactly is the performance gain from writing
views/shows/ etc in Erlang vs JavaScript... From what I've seen
views/shows/ etc in Erlang vs JavaScript... From what I've seen the
JavaScript view server is sufficiently fast and feature complete.
So my question is this Is the Erlang view server that much faster?...
Is there another gain that I'm missing?..and is it as feature complete
background. You can
measure it with you functions and data and share with us (:
--
,,,^..^,,,
On Wed, Aug 14, 2013 at 8:54 PM, Stanley Iriele siriele...@gmail.com
wrote:
I'm curious... What exactly is the performance gain from writing
views/shows/ etc in Erlang vs JavaScript... From
On Wed, Aug 14, 2013 at 9:17 PM, Stanley Iriele siriele...@gmail.com wrote:
Oh wow...that is pretty snazzythis is a bit of a dumb question but can
everything in a design doc be written in Erlang?..like list
functions..shows..etc?
Yes, you can write any design functions on Erlang.
vs JavaScript... From what I've seen the
JavaScript view server is sufficiently fast and feature complete.
So my question is this Is the Erlang view server that much
faster?...
Is there another gain that I'm missing?..and is it as feature complete
as
the JavaScript equivalent
background. You can
measure it with you functions and data and share with us (:
--
,,,^..^,,,
On Wed, Aug 14, 2013 at 8:54 PM, Stanley Iriele siriele...@gmail.com
wrote:
I'm curious... What exactly is the performance gain from writing
views/shows/ etc in Erlang vs JavaScript
On Aug 14, 2013, at 10:02 AM, Alexander Shorin kxe...@gmail.com wrote:
Erlang server bypassed stdio interface communication and addtional
JSON decode/encode roundtrip, so it is faster than JS at some point.
Yeah — the ironic thing is that state-of-the-art JS runtimes are probably
faster than
On Wed, Aug 14, 2013 at 11:50 PM, Jens Alfke j...@couchbase.com wrote:
On Aug 14, 2013, at 10:02 AM, Alexander Shorin kxe...@gmail.com wrote:
Erlang server bypassed stdio interface communication and addtional
JSON decode/encode roundtrip, so it is faster than JS at some point.
Yeah — the
The bottleneck is not the language used to write the Query Server, but it's the
standard input/output used for inter-process communication.
Why not use 0MQ instead?
On Aug 14, 2013, at 1:57 PM, Filippo Fadda filippo.fa...@programmazione.it
wrote:
The bottleneck is not the language used to write the Query Server, but it's
the standard input/output used for inter-process communication.
That’s basically what I’m saying, if you include the JSON marshaling
/shows/ etc in Erlang vs JavaScript... From what I've seen the
JavaScript view server is sufficiently fast and feature complete.
So my question is this Is the Erlang view server that much faster?...
Is there another gain that I'm missing?..and is it as feature complete as
the JavaScript
in Erlang vs JavaScript... From what I've seen the
JavaScript view server is sufficiently fast and feature complete.
So my question is this Is the Erlang view server that much faster?...
Is there another gain that I'm missing?..and is it as feature complete as
the JavaScript equivalent
vs JavaScript... From what I've seen the
JavaScript view server is sufficiently fast and feature complete.
So my question is this Is the Erlang view server that much
faster?...
Is there another gain that I'm missing?..and is it as feature complete
as
the JavaScript equivalent
docs to Erlang. Like a breath of fresh air, if you ask me.
Andrey
On Wed, Aug 14, 2013 at 11:54 PM, Stanley Iriele siriele...@gmail.com
wrote:
I'm curious... What exactly is the performance gain from writing
views/shows/ etc in Erlang vs JavaScript... From what I've
views/shows/ etc in Erlang vs JavaScript... From what I've seen the
JavaScript view server is sufficiently fast and feature complete.
So my question is this Is the Erlang view server that much
faster?...
Is there another gain that I'm missing?..and is it as feature
The time complexity of Erlang vs. JavaScript views is the same, O(n) where
n is the document count.
View building time feels important during development but it is irrelevant
during operation. Production servers never hold up requests to build views,
so the performance is secondary. For very
AM, Jason Smith j...@apache.org wrote:
The time complexity of Erlang vs. JavaScript views is the same, O(n) where
n is the document count.
View building time feels important during development but it is irrelevant
during operation. Production servers never hold up requests to build views,
so
On Aug 14, 2013, at 8:52 PM, Jason Smith j...@apache.org wrote:
View building time feels important during development but it is irrelevant
during operation. Production servers never hold up requests to build views,
so the performance is secondary.
Wait, what? I may be mis-reading that, but
Nope, not misreading anything. And I understand they do. But the sooner
they finish the better, wont you agree? It's mainly because of that we dont
do view updates during weekdays. So we normally wait until Sunday, in order
to make sure that no users are affected by degraded server performance.
On Aug 14, 2013, at 9:53 PM, Andrey Kuprianov andrey.koupria...@gmail.com
wrote:
Nope, not misreading anything. And I understand they do. But the sooner
they finish the better, wont you agree? It's mainly because of that we dont
do view updates during weekdays.
OK, you must be using CouchDB
I see what you mean now. Thing is that we are actively moving from MySQL to
Couch now and migrating tons of data at a time. So in return all the views
need to catch up with all of those new documents. Erlang seems to be a
promising candidate to speed up our development. That's all. I just tried
it
50 matches
Mail list logo
