Re: [racket-users] A template/example to use to build a workflow illustration/flowchart in slideshow

[WarGrey Gyoudmon Ju]

you can use (system) run graphviz, then load the resulting picture into
slideshow with (bitmap) of pict.

On Sat, Jan 16, 2016 at 8:22 AM, ckkashyap  wrote:

> Thanks Jordan ... I was aware of the tutorial source ... I was looking for
> something that let me draw a flowchart quickly - I used graphviz for it and
> it worked for me :)
>
> Regards,
> Kashyap
>
> On Friday, January 15, 2016 at 10:19:55 AM UTC-8, Jordan Johnson wrote:
> > Yes. The slideshow tutorial referenced near the top of
> >  http://docs.racket-lang.org/slideshow/index.html
> > ("Run Tutorial") incorporates a slideshow in which you can inspect the
> source.
> >
> >
> > Best,
> > Jordan
> >
> > On Jan 13, 2016, at 5:10 PM, C K Kashyap  wrote:
> >
> >
> >
> > Dear group,
> >
> >
> > I am trying to use racket for my presentation - essentially document the
> flow of code of a system I've been going through for a few days - I was
> wondering if there is a slideshow example that I could use to build on top
> of to illustrate a workflow.
> >
> >
> > Regards,
> > Kashyap
> >
> >
> >
> >
> > --
> >
> > You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> >
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users...@googlegroups.com.
> >
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Typo in license.html.

[Dmitry Igrishin]

Hello,

I've noticed a typo at https://download.racket-lang.org/license.html
- a double "for for" here:

"We have chosen the LGPL as the license for Racket, which makes it possible
for for"

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Profiling help

[Vincent St-Amour]

Brian,

The Racket profiler is an edge profiler. So in addition to telling you
which code time is spent in, it's also telling you which callers caused
which proportion of that time.

In the case of [48], it's telling you that file output is a significant
bottleneck, and that it's caused by the code at [2], [38], [39], etc.
(as well as by recursive calls to `call-with-output-file`).

As for the `for` ([49]), the loops at [40] and [37] are the main
culprits.

Based on that, you could try redirecting output to `open-output-nowhere`
if you want to profile your computation (as opposed to output), or you
could try batching your output (fewer, larger `printf`s instead of many
small ones) to reduce the cost of output.

Vincent




On Sat, 16 Jan 2016 16:51:04 -0600,
Brian Adkins wrote:
> 
> I'm not sure if something changed with 6.3, but I have the output of:
> 
> racket -l errortrace -t parser.rkt
> 
> in the following gist:
> 
> https://gist.githubusercontent.com/lojic/9cd8a3a88ef2e110b9de/raw/79e9892326101333d11987c8e3a3b9df93adc63a/profile%2520output
> 
> I'm having trouble understanding the output. For example, I see that [48] ... 
> (49.6%)  is probably an area I need to look at, but I can't tell what part of 
> my code I should look at from that output. Likewise for the 19.4% reported 
> for "for".
> 
> Any ideas?
> 
> Thanks,
> Brian
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Profiling help

[Vincent St-Amour]

Looks like that run had more useful info.

Your uses of `string-trim` and `fprintf` are probably worth
investigating.

Vincent



On Sat, 16 Jan 2016 21:01:22 -0600,
Brian Adkins wrote:
> 
> On Saturday, January 16, 2016 at 9:40:51 PM UTC-5, Vincent St-Amour wrote:
> > Brian,
> > 
> > The Racket profiler is an edge profiler. So in addition to telling you
> > which code time is spent in, it's also telling you which callers caused
> > which proportion of that time.
> > 
> > In the case of [48], it's telling you that file output is a significant
> > bottleneck, and that it's caused by the code at [2], [38], [39], etc.
> > (as well as by recursive calls to `call-with-output-file`).
> > 
> > As for the `for` ([49]), the loops at [40] and [37] are the main
> > culprits.
> > 
> > Based on that, you could try redirecting output to `open-output-nowhere`
> > if you want to profile your computation (as opposed to output), or you
> > could try batching your output (fewer, larger `printf`s instead of many
> > small ones) to reduce the cost of output.
> > 
> > Vincent
> 
> Thanks. I used open-output-nowhere and got the following profile info:
> 
> https://gist.githubusercontent.com/lojic/db6e02d0d9d88e1d5ced/raw/1002b6e6ee14f2c59b067abe6eac0488a3f2dc7a/profile.txt
> 
> I was surprised that using open-output-nowhere is actually slower though !!  
> Runtime was 13,761ms vs. 10,258ms with real I/O.
> 
> I'm going to follow up another thread I started a while back with more 
> performance info.
> 
> It's definitely a CPU bound app (only able to write about 4 MB/s). Even the C 
> version (see other thread shortly) is CPU bound, and it's pushing 90+ MB/s to 
> disk. I have an SSD.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Profiling help

[Brian Adkins]

I'm not sure if something changed with 6.3, but I have the output of:

racket -l errortrace -t parser.rkt

in the following gist:

https://gist.githubusercontent.com/lojic/9cd8a3a88ef2e110b9de/raw/79e9892326101333d11987c8e3a3b9df93adc63a/profile%2520output

I'm having trouble understanding the output. For example, I see that [48] ... 
(49.6%)  is probably an area I need to look at, but I can't tell what part of 
my code I should look at from that output. Likewise for the 19.4% reported for 
"for".

Any ideas?

Thanks,
Brian

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Racket performance tips

[Brian Adkins]

On Saturday, January 16, 2016 at 11:22:14 PM UTC-5, Alexis King wrote:
> Those programs appear to depend on input files. Is there any way you could 
> provide those inputs or otherwise make the programs self-contained? I might 
> be interested in taking a look at them, but it’s hard to get a feel for 
> what’s going on without being able to run the programs.
> 
> > On Jan 16, 2016, at 19:32, Brian Adkins wrote:
> > 
> > A while ago, I started a thread about whether Rust or C would be a better 
> > complement to Racket. After much more Rust research/coding, I got very 
> > tired of fighting the compiler, so I decided to blow the dust off my C 
> > skills (I haven't done any serious coding in C since 1996), and code up the 
> > app in C.
> > 
> > In about 2.5 hours, I had coded as much of the app in C as had taken many 
> > more hours in Rust and it was about 2.5x faster and *much* easier to 
> > understand. I knew exactly what I wanted to do for maximum performance, but 
> > I found myself constantly fighting Rust. I've concluded that, for me, C is 
> > a better complement.
> > 
> > Anyway, the purpose for this post is to ask for some assistance in getting 
> > the best performance out of my Racket code. After choosing a different 
> > soundex algorithm, I was a little disappointed in the following runtime 
> > numbers for identical functionality:
> > 
> > Racket = 10.3s
> > Ruby = 7.61s
> > C = 0.472s
> > 
> > Those are numbers for parsing 200K records in a fixed width format to 
> > create a postgres bulk input file. The real data contains 45+M records, so 
> > speed is a consideration (e.g. 1.8 min. for C vs. 38.6 min. for Racket)
> > 
> > It's the fact that Racket is currently slower than Ruby which is bugging 
> > me. Despite my rusty (no pun intended) C skills, I was able to hack a 
> > version that does zero heap allocation and is pretty speedy, so I wouldn't 
> > expect Racket to get close to it. On the other hand, I *would* definitely 
> > hope the Racket version can beat the Ruby version.
> > 
> > Here are the programs:
> > 
> > C: https://gist.github.com/lojic/4369d9d57eb775296c92
> > 
> > Ruby: https://gist.github.com/lojic/2b91fde8e6bbb7bab1cd
> > 
> > Racket: https://gist.github.com/lojic/f306104846d516761952
> > 
> > They have identical output (I measured through the first 4M input records), 
> > and they are very similar (same functions, etc.) in style.
> > 
> > Latest profile output from Racket (using open-output-nowhere as suggested 
> > by Vincent):
> > 
> > https://gist.githubusercontent.com/lojic/db6e02d0d9d88e1d5ced/raw/1002b6e6ee14f2c59b067abe6eac0488a3f2dc7a/profile.txt
> > 
> > Earlier today, I had a hacked up Racket version with manual loops, etc., 
> > but then I thought that I really shouldn't have to resort to that to beat 
> > Ruby, so I returned the Racket code to a form that was most similar to 
> > Ruby. For example:
> > 
> > Ruby:
> > 
> >  def self.parse_string line, beg, len
> >line[beg,len].gsub("\\", '').strip
> >  end
> > 
> > Racket:
> > 
> > (define (parse-string line beg end)
> >  (string-trim (string-replace (substring line beg end) "\\" "")))
> > 
> > But I think the Ruby runtime is a little more optimized currently. In 
> > particular, I suspect string-replace vs. gsub, string-trim vs. strip, etc.
> > 
> > The real fun will come when I use a places version of the Racket code, but 
> > I want to get decent linear speed before parallelizing.
> > 
> > Ruby has no JIT, and both Ruby and Racket of C runtimes, so there doesn't 
> > seem to be any fundamental reason why similar code shouldn't perform better 
> > in Racket.
> > 
> > By the way, I compared Racket 6.2.1 with 6.3 and the latter is 10.4% faster 
> > for this app, so that was encouraging.
> > 
> > Any help is greatly appreciated!
> > 
> > Brian
> > 

Unfortunately, the data is criminal records, so there would be a lot of fields 
to anonymize before I could make it public.

I'm happy to run experiments and report timings though.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Racket performance tips

[Brian Adkins]

On Saturday, January 16, 2016 at 11:26:14 PM UTC-5, Neil Van Dyke wrote:
> Your code is very string-ops-heavy, and I would start looking at that.  
> One thing you could do is look for opportunities to construct fewer 
> intermediate strings, including across multiple procedure calls.  You 
> could also look for operations that are expensive, and use 
> less-expensive ones.  If your strings have no multibyte characters, it'd 
> be easier to make it a lot faster with reused bytes I/O buffers and a 
> tons less copying, but you could also try that with multibyte characters 
> (it's harder and slower, though).
> 
> If you get fancy with the optimization, you might end up with a DSL or 
> mini-language for the formats and/or transformation, to simplify the 
> source code while making its behavior more sophisticated.  But maybe you 
> want to focus on a proof-of-concept for the optimizations first, before 
> you go to the work of implementing the DSL.
> 
> BTW, the below comment, from an aborted response to your previous email, 
> doesn't seem to apply to your code, but I'll just note it for the record:
> 
> >
> > Without tracing through the actual code being profiled (not 
> > volunteering!), it's hard to say what the fix is.
> >
> > One little tip, from glancing at "collects/racket/string.rkt"... If 
> > your code happens to be calling `string-trim` with a large number of 
> > different `sep` arguments (different by `eq?`), it looks like it will 
> > be especially slow.  Or if you're calling `string-trim` a huge number 
> > of times with a nonzero number of non-`#f` `sep` arguments, and you're 
> > GCing.  (The implementation assembles regular expressions for non-`#f` 
> > `sep` arguments, and caches them in a weak hash with `eq?` test.)
> 
> BTW, I wouldn't be surprised if `string-trim` could be made faster for 
> the normal case of `sep` being `#f`, though the code doesn't look bad 
> right now.  (The majority of code that people write is not very 
> efficient, and `string-trim` looks better than the norm.) However, it 
> was written in a generalized way, and I don't know if anyone sat down 
> and hand-optimized for the `#f` case specifically. Or, it might have 
> been written a long time ago, and the VM/compiler or strings have 
> changed quite a bit since then, and so the code could benefit from 
> re-hand-optimizing.  (I've done a bunch of that kind of optimizing as a 
> consultant, and it can easily take a few hours for a single procedure, 
> so tends to only happen as-needed.)
> 
> Neil V.

For this app, the data is actually straight ASCII upper case mainframe data :)

Can you elaborate re: "reused bytes I/O buffers "  ?  One of the things I did 
in the C code was to reuse character arrays a lot and never malloc, but I'm 
less familiar with doing similar things in Racket.

I'm not opposed to hand optimizing (the C program was basically one gigantic 
optimization), but to be fair, it seems the same optimizations would need to be 
done to the Ruby code for comparison.

In other words, I have two related, but different goals:

1) I'd like to get to the point of being able to write expressive, "high level" 
code in Racket, in a similar manner as I've been accustomed to with Ruby, but 
with better performance than Ruby. Given Ruby typically trails the pack with 
respect to speed, that doesn't seem unreasonable.

2) I'd also like to get a better idea of practical optimizations that I can use 
with Racket when I need more speed, even if it lessens other aspects of the 
code such as readability, etc. I suppose the string-squeeze function in the 
Racket code is an example of that.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Profiling help

[Brian Adkins]

On Saturday, January 16, 2016 at 9:40:51 PM UTC-5, Vincent St-Amour wrote:
> Brian,
> 
> The Racket profiler is an edge profiler. So in addition to telling you
> which code time is spent in, it's also telling you which callers caused
> which proportion of that time.
> 
> In the case of [48], it's telling you that file output is a significant
> bottleneck, and that it's caused by the code at [2], [38], [39], etc.
> (as well as by recursive calls to `call-with-output-file`).
> 
> As for the `for` ([49]), the loops at [40] and [37] are the main
> culprits.
> 
> Based on that, you could try redirecting output to `open-output-nowhere`
> if you want to profile your computation (as opposed to output), or you
> could try batching your output (fewer, larger `printf`s instead of many
> small ones) to reduce the cost of output.
> 
> Vincent

Thanks. I used open-output-nowhere and got the following profile info:

https://gist.githubusercontent.com/lojic/db6e02d0d9d88e1d5ced/raw/1002b6e6ee14f2c59b067abe6eac0488a3f2dc7a/profile.txt

I was surprised that using open-output-nowhere is actually slower though !!  
Runtime was 13,761ms vs. 10,258ms with real I/O.

I'm going to follow up another thread I started a while back with more 
performance info.

It's definitely a CPU bound app (only able to write about 4 MB/s). Even the C 
version (see other thread shortly) is CPU bound, and it's pushing 90+ MB/s to 
disk. I have an SSD.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Racket performance tips

[Neil Van Dyke]

Your code is very string-ops-heavy, and I would start looking at that.  
One thing you could do is look for opportunities to construct fewer 
intermediate strings, including across multiple procedure calls.  You 
could also look for operations that are expensive, and use 
less-expensive ones.  If your strings have no multibyte characters, it'd 
be easier to make it a lot faster with reused bytes I/O buffers and a 
tons less copying, but you could also try that with multibyte characters 
(it's harder and slower, though).


If you get fancy with the optimization, you might end up with a DSL or 
mini-language for the formats and/or transformation, to simplify the 
source code while making its behavior more sophisticated.  But maybe you 
want to focus on a proof-of-concept for the optimizations first, before 
you go to the work of implementing the DSL.


BTW, the below comment, from an aborted response to your previous email, 
doesn't seem to apply to your code, but I'll just note it for the record:




Without tracing through the actual code being profiled (not 
volunteering!), it's hard to say what the fix is.


One little tip, from glancing at "collects/racket/string.rkt"... If 
your code happens to be calling `string-trim` with a large number of 
different `sep` arguments (different by `eq?`), it looks like it will 
be especially slow.  Or if you're calling `string-trim` a huge number 
of times with a nonzero number of non-`#f` `sep` arguments, and you're 
GCing.  (The implementation assembles regular expressions for non-`#f` 
`sep` arguments, and caches them in a weak hash with `eq?` test.)


BTW, I wouldn't be surprised if `string-trim` could be made faster for 
the normal case of `sep` being `#f`, though the code doesn't look bad 
right now.  (The majority of code that people write is not very 
efficient, and `string-trim` looks better than the norm.) However, it 
was written in a generalized way, and I don't know if anyone sat down 
and hand-optimized for the `#f` case specifically. Or, it might have 
been written a long time ago, and the VM/compiler or strings have 
changed quite a bit since then, and so the code could benefit from 
re-hand-optimizing.  (I've done a bunch of that kind of optimizing as a 
consultant, and it can easily take a few hours for a single procedure, 
so tends to only happen as-needed.)


Neil V.

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Racket performance tips

[WarGrey Gyoudmon Ju]

Yes.
What Bytes in Racket is what char * in C.
String treats the chars as a UTF-8 value.

On Sun, Jan 17, 2016 at 12:59 PM, Brian Adkins 
wrote:

> On Saturday, January 16, 2016 at 11:54:05 PM UTC-5, Brian Adkins wrote:
> > On Saturday, January 16, 2016 at 11:26:14 PM UTC-5, Neil Van Dyke wrote:
> > > Your code is very string-ops-heavy, and I would start looking at that.
> > > One thing you could do is look for opportunities to construct fewer
> > > intermediate strings, including across multiple procedure calls.  You
> > > could also look for operations that are expensive, and use
> > > less-expensive ones.  If your strings have no multibyte characters,
> it'd
> > > be easier to make it a lot faster with reused bytes I/O buffers and a
> > > tons less copying, but you could also try that with multibyte
> characters
> > > (it's harder and slower, though).
> > >
> > > If you get fancy with the optimization, you might end up with a DSL or
> > > mini-language for the formats and/or transformation, to simplify the
> > > source code while making its behavior more sophisticated.  But maybe
> you
> > > want to focus on a proof-of-concept for the optimizations first, before
> > > you go to the work of implementing the DSL.
> > >
> > > BTW, the below comment, from an aborted response to your previous
> email,
> > > doesn't seem to apply to your code, but I'll just note it for the
> record:
> > >
> > > >
> > > > Without tracing through the actual code being profiled (not
> > > > volunteering!), it's hard to say what the fix is.
> > > >
> > > > One little tip, from glancing at "collects/racket/string.rkt"... If
> > > > your code happens to be calling `string-trim` with a large number of
> > > > different `sep` arguments (different by `eq?`), it looks like it will
> > > > be especially slow.  Or if you're calling `string-trim` a huge number
> > > > of times with a nonzero number of non-`#f` `sep` arguments, and
> you're
> > > > GCing.  (The implementation assembles regular expressions for
> non-`#f`
> > > > `sep` arguments, and caches them in a weak hash with `eq?` test.)
> > >
> > > BTW, I wouldn't be surprised if `string-trim` could be made faster for
> > > the normal case of `sep` being `#f`, though the code doesn't look bad
> > > right now.  (The majority of code that people write is not very
> > > efficient, and `string-trim` looks better than the norm.) However, it
> > > was written in a generalized way, and I don't know if anyone sat down
> > > and hand-optimized for the `#f` case specifically. Or, it might have
> > > been written a long time ago, and the VM/compiler or strings have
> > > changed quite a bit since then, and so the code could benefit from
> > > re-hand-optimizing.  (I've done a bunch of that kind of optimizing as a
> > > consultant, and it can easily take a few hours for a single procedure,
> > > so tends to only happen as-needed.)
> > >
> > > Neil V.
> >
> > For this app, the data is actually straight ASCII upper case mainframe
> data :)
> >
> > Can you elaborate re: "reused bytes I/O buffers "  ?  One of the things
> I did in the C code was to reuse character arrays a lot and never malloc,
> but I'm less familiar with doing similar things in Racket.
> >
> > I'm not opposed to hand optimizing (the C program was basically one
> gigantic optimization), but to be fair, it seems the same optimizations
> would need to be done to the Ruby code for comparison.
> >
> > In other words, I have two related, but different goals:
> >
> > 1) I'd like to get to the point of being able to write expressive, "high
> level" code in Racket, in a similar manner as I've been accustomed to with
> Ruby, but with better performance than Ruby. Given Ruby typically trails
> the pack with respect to speed, that doesn't seem unreasonable.
> >
> > 2) I'd also like to get a better idea of practical optimizations that I
> can use with Racket when I need more speed, even if it lessens other
> aspects of the code such as readability, etc. I suppose the string-squeeze
> function in the Racket code is an example of that.
>
> So, maybe replace in-lines with in-bytes-lines on line 31 of
> https://gist.github.com/lojic/f306104846d516761952 and flow Byte Strings
> through the app instead of Strings given the source being ASCII chars ?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Racket performance tips

[Brian Adkins]

On Saturday, January 16, 2016 at 11:54:05 PM UTC-5, Brian Adkins wrote:
> On Saturday, January 16, 2016 at 11:26:14 PM UTC-5, Neil Van Dyke wrote:
> > Your code is very string-ops-heavy, and I would start looking at that.  
> > One thing you could do is look for opportunities to construct fewer 
> > intermediate strings, including across multiple procedure calls.  You 
> > could also look for operations that are expensive, and use 
> > less-expensive ones.  If your strings have no multibyte characters, it'd 
> > be easier to make it a lot faster with reused bytes I/O buffers and a 
> > tons less copying, but you could also try that with multibyte characters 
> > (it's harder and slower, though).
> > 
> > If you get fancy with the optimization, you might end up with a DSL or 
> > mini-language for the formats and/or transformation, to simplify the 
> > source code while making its behavior more sophisticated.  But maybe you 
> > want to focus on a proof-of-concept for the optimizations first, before 
> > you go to the work of implementing the DSL.
> > 
> > BTW, the below comment, from an aborted response to your previous email, 
> > doesn't seem to apply to your code, but I'll just note it for the record:
> > 
> > >
> > > Without tracing through the actual code being profiled (not 
> > > volunteering!), it's hard to say what the fix is.
> > >
> > > One little tip, from glancing at "collects/racket/string.rkt"... If 
> > > your code happens to be calling `string-trim` with a large number of 
> > > different `sep` arguments (different by `eq?`), it looks like it will 
> > > be especially slow.  Or if you're calling `string-trim` a huge number 
> > > of times with a nonzero number of non-`#f` `sep` arguments, and you're 
> > > GCing.  (The implementation assembles regular expressions for non-`#f` 
> > > `sep` arguments, and caches them in a weak hash with `eq?` test.)
> > 
> > BTW, I wouldn't be surprised if `string-trim` could be made faster for 
> > the normal case of `sep` being `#f`, though the code doesn't look bad 
> > right now.  (The majority of code that people write is not very 
> > efficient, and `string-trim` looks better than the norm.) However, it 
> > was written in a generalized way, and I don't know if anyone sat down 
> > and hand-optimized for the `#f` case specifically. Or, it might have 
> > been written a long time ago, and the VM/compiler or strings have 
> > changed quite a bit since then, and so the code could benefit from 
> > re-hand-optimizing.  (I've done a bunch of that kind of optimizing as a 
> > consultant, and it can easily take a few hours for a single procedure, 
> > so tends to only happen as-needed.)
> > 
> > Neil V.
> 
> For this app, the data is actually straight ASCII upper case mainframe data :)
> 
> Can you elaborate re: "reused bytes I/O buffers "  ?  One of the things I did 
> in the C code was to reuse character arrays a lot and never malloc, but I'm 
> less familiar with doing similar things in Racket.
> 
> I'm not opposed to hand optimizing (the C program was basically one gigantic 
> optimization), but to be fair, it seems the same optimizations would need to 
> be done to the Ruby code for comparison.
> 
> In other words, I have two related, but different goals:
> 
> 1) I'd like to get to the point of being able to write expressive, "high 
> level" code in Racket, in a similar manner as I've been accustomed to with 
> Ruby, but with better performance than Ruby. Given Ruby typically trails the 
> pack with respect to speed, that doesn't seem unreasonable.
> 
> 2) I'd also like to get a better idea of practical optimizations that I can 
> use with Racket when I need more speed, even if it lessens other aspects of 
> the code such as readability, etc. I suppose the string-squeeze function in 
> the Racket code is an example of that.

So, maybe replace in-lines with in-bytes-lines on line 31 of 
https://gist.github.com/lojic/f306104846d516761952 and flow Byte Strings 
through the app instead of Strings given the source being ASCII chars ?

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Racket performance tips

[Neil Van Dyke]

Brian Adkins wrote on 01/16/2016 11:54 PM:

Can you elaborate re: "reused bytes I/O buffers "  ?  One of the things I did 
in the C code was to reuse character arrays a lot and never malloc, but I'm less familiar 
with doing similar things in Racket.


Look at `read-bytes!`, `read-bytes-avail!`, and related procedures. 
Preferably on a buffer you reuse for each record.  And remember that you 
don't always need to copy -- you can pass around byte range indexes, and 
you can even mutate the buffer.  Then do something like you would in C 
(just with no pointer arithmetic, but at least you get safety and access 
to the higher-level language when you want).



1) I'd like to get to the point of being able to write expressive, "high level" 
code in Racket, in a similar manner as I've been accustomed to with Ruby, but with better 
performance than Ruby. Given Ruby typically trails the pack with respect to speed, that 
doesn't seem unreasonable.


I've found Racket performance acceptable for most purposes, including 
the general kind of records processing you're doing.  I suspect the 
difference you're seeing in this case is due to something like some of 
Ruby's string ops being faster than Racket's (if that's true).


Neil V.

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Racket performance tips

[Jon Zeppieri]

On Sat, Jan 16, 2016 at 11:29 PM, Brian Adkins 
wrote:

>
> I'm happy to run experiments and report timings though.
>
>
Since the profile suggests that string-trim is the biggest culprit
(followed by fprintf), try using this specialized version of string-trim
locally:

;; ===
(require racket/unsafe/ops)

(define (string-trim s)
  (define len (string-length s))

  (let loop ([i 0])
(cond [(unsafe-fx< i len)
   (cond [(char-whitespace? (unsafe-string-ref s i))
  (loop (unsafe-fx+ i 1))]
 [else
  (let inner ([j (unsafe-fx- len 1)])
(cond [(char-whitespace? (unsafe-string-ref s j))
   (inner (unsafe-fx- j 1))]
  [else
   (substring s i (unsafe-fx+ j 1))]))])]
[else
 s])))
;; ===

Instead of fprintf-ing the tabbed values, you might try (displayln
(string-join fields "\t")). Of course, that requires building a list of
strings, which has its own cost.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.