On Tuesday, 3 June 2014 at 06:39:04 UTC, Jacob Carlborg wrote:
On 02/06/14 21:13, Sean Kelly wrote:
I'm starting to wonder if I
should just try and get permission from work to open source my
parser so I can submit it.
That would be awesome. Is it written in D or was it C++ ?
It's written in
On Monday, 2 June 2014 at 00:18:19 UTC, David Soria Parra wrote:
Hi,
I have recently had to deal with large amounts of JSON data in
D. While doing that I've found that std.json is remarkable slow
in comparison to other languages standard json implementation.
I've create a small and simple ben
On 03/06/14 09:15, Johannes Pfau wrote:
I'd probably prefer a tokenizer/lexer as the lowest layer, then SAX and
DOM implemented using the tokenizer. This way we can provide a kind of
input range. I actually used Brian Schotts std.lexer proposal to build a
simple JSON tokenizer/lexer and it worke
On Monday, 2 June 2014 at 00:18:19 UTC, David Soria Parra wrote:
Hi,
I have recently had to deal with large amounts of JSON data in
D. While doing that I've found that std.json is remarkable slow
in comparison to other languages standard json implementation.
I've create a small and simple ben
Am 02.06.2014 21:13, schrieb Sean Kelly:
The vibe.d parser is better, but it still creates a DOM-style
tree of objects, which isn't acceptable in some circumstances. I
posted a performance comparison of the JSON parser I created for
work use with std.json a while back, and mine is almost 100x
fa
On Mon, 02 Jun 2014 19:13:07 +
Sean Kelly via Digitalmars-d wrote:
> I've said this a bunch of times, but what I want to see is a
> SAX-style parser as the bottom layer with an optional DOM-style
> parser built on top of it. Then people who want the tree
> generated can get it, and people wh
Am Mon, 02 Jun 2014 19:13:07 +
schrieb "Sean Kelly" :
> I've said this a bunch of times, but what I want to see is a
> SAX-style parser as the bottom layer with an optional DOM-style
> parser built on top of it.
I'd probably prefer a tokenizer/lexer as the lowest layer, then SAX and
DOM impl
On 02/06/14 21:13, Sean Kelly wrote:
The vibe.d parser is better, but it still creates a DOM-style
tree of objects, which isn't acceptable in some circumstances. I
posted a performance comparison of the JSON parser I created for
work use with std.json a while back, and mine is almost 100x
faster
On 02/06/14 21:13, Sean Kelly wrote:
I'm starting to wonder if I
should just try and get permission from work to open source my
parser so I can submit it.
That would be awesome. Is it written in D or was it C++ ?
--
/Jacob Carlborg
On Monday, 2 June 2014 at 20:10:52 UTC, David Soria Parra wrote:
I think the main question is, given that std.json is close to
be unusable for anything serious due to it's poor performance,
can we come up with something faster that has the same API. I
am not sure what phobos take on backwards c
On Monday, 2 June 2014 at 19:05:15 UTC, Chris Williams wrote:
In general, I've been pretty happy with vibe.d, and I've heard
that the parser speed of the JSON implementation is good. But I
must admit that I found the API to be fairly obtuse. In order
to do much of anything, you really need to
The vibe.d parser is better, but it still creates a DOM-style
tree of objects, which isn't acceptable in some circumstances. I
posted a performance comparison of the JSON parser I created for
work use with std.json a while back, and mine is almost 100x
faster than std.json in a simple test and al
On Monday, 2 June 2014 at 00:39:48 UTC, Jonathan M Davis via
Digitalmars-d wrote:
I know that vibe.d uses its own json implementation, but I
don't know
how much of that is part of its public API and how much of that
is
simply used internally: http://vibed.org
In general, I've been pretty happ
On 02/06/14 13:36, w0rp wrote:
In terms of API, I wouldn't go completely for an approach based on
serialising to structs. Having a tagged union type is still helpful for
situations where you just want to quickly get at some JSON data and do
something with it. I have thought a great deal about wr
It's worth noting, "pretty printing" could be configured entirely
in an OutputRange which watches for certain syntax coming into
the range and inserts whitespace where it believes to be
appropriate, so writeJSON functions would not need to know
anything about pretty printing.
On Monday, 2 June 2014 at 00:39:48 UTC, Jonathan M Davis via
Digitalmars-d wrote:
It's my understanding that the current design of std.json is
considered
to be poor, but I don't haven't used it, so I don't know any the
details. But if it's as slow as you're finding to be the case,
then I
think
On Monday, 2 June 2014 at 00:18:19 UTC, David Soria Parra wrote:
Would it make sense to start thinking about using ujson4c as an
external library, or maybe come up with a better
implementation. I know Orvid has something and might add some
analysis as to why std.json is slow. Any ideas or point
On Mon, 02 Jun 2014 00:18:18 +
David Soria Parra via Digitalmars-d wrote:
> Hi,
>
> I have recently had to deal with large amounts of JSON data in D.
> While doing that I've found that std.json is remarkable slow in
> comparison to other languages standard json implementation. I've
> create a
Hi,
I have recently had to deal with large amounts of JSON data in D.
While doing that I've found that std.json is remarkable slow in
comparison to other languages standard json implementation. I've
create a small and simple benchmark parsing a local copy of a
github API call
"https://api.gi
19 matches
Mail list logo
