Another option would be to just overload equal? in match.scm to transform into
eqv? when there are char literals or numbers, eq? on symbols, booleans, the
empty list and keywords and (@@ (guile) equal?) for everything else.
Considering that it in this case contributed a 25% overhead to code tha
You didn't see my other reply. The matching code isn't suboptimal. The equality
predicate is The problem is that match compares using equal? even for literal
chars (where eqv? is a lot faster). It would be a rather trivial optimization
to do, either to match.scm (meaning: breaking with upstream
Hi,
Linus Björnstam skribis:
> On Mon, 4 May 2020, at 11:36, Ludovic Courtès wrote:
>
>> > One thing I found is that `match` is slow. The code looked nicer but had
>> > to change it back to lets and conds as the performance
>> > increase was ~2 seconds.
>>
>> Oh, in which case exactly? And
Sorry, sent a premature reply. The problem is that some of those match blocks
expand to using equal? which is a lot slower than using eqv? If we are doing it
on every char in a 24mb file we are getting some serious constant factors.
match is a syntax-rules macro, so distinguishing literals are
On Mon, 4 May 2020, at 11:36, Ludovic Courtès wrote:
> > One thing I found is that `match` is slow. The code looked nicer but had to
> > change it back to lets and conds as the performance
> > increase was ~2 seconds.
>
> Oh, in which case exactly? And are you sure your hand-written code is
Hey!
Aleix Conchillo Flaqué skribis:
> So weird I'm getting different numbers on 2.2.7. Not sure how I'm getting
> those initial ~20s and you are getting consistent ~ 45s. It
> shouldn't have nothing to do with it, but could it be I'm running it on macOS?
Did you add this ‘->bool’ call to ensu
On Sat, May 2, 2020 at 7:11 AM Ludovic Courtès wrote:
> Hola!
>
>
Hola!
So weird I'm getting different numbers on 2.2.7. Not sure how I'm getting
those initial ~20s and you are getting consistent ~ 45s. It shouldn't have
nothing to do with it, but could it be I'm running it on macOS?
Now, it wo
Hola!
Aleix Conchillo Flaqué skribis:
> On guile-json 3.5.0 (still using (string-append)) the first execution time
> goes from 19 seconds to 42 seconds. Then, the times keep increasing as in
> version 2.2.7 but numbers are much bigger:
With Guile 3.0.2 and Guile-JSON 3.5.0, I get:
--8<
On Sun, Apr 26, 2020 at 10:16 AM Ludovic Courtès wrote:
> Bon dia!
>
>
Bon dia! And bon jour! :-D
> Aleix Conchillo Flaqué skribis:
>
> > I was trying to get some guile-json performance times loading large JSON
> > file. However, I'm getting increasing numbers at each run, so I'm
> wondering
>
Bon dia!
Aleix Conchillo Flaqué skribis:
> I was trying to get some guile-json performance times loading large JSON
> file. However, I'm getting increasing numbers at each run, so I'm wondering
> if I'm doing something wrong. Below you can see how the first run took
> 19.95s and then running the
Hi Aleix
Try throwing the result of json->SCM away: (let ((a (call-with...))) 1). Then
you can run a (gc) between runs. If the GC time increases then, maybe guile
cannot release the memory?? I don't know, but there is some shared substring
thing going on in guile, even though I think string-app
11 matches
Mail list logo
