Re: [racket-users] Racket performance tips

I have a few minor stile comments: *** I'd replace (define backslash 92) with (define backslash (char->integer #\\)) to improve legibility. And do the same replacement for other magic numbers. After optimization, both versions are identical. [The only site where this would cause a

Re: [racket-users] Racket performance tips

On Monday, January 18, 2016 at 10:23:56 AM UTC-5, gustavo wrote: > I have a few minor stile comments: > > *** I'd replace >(define backslash 92) > with >(define backslash (char->integer #\\)) > to improve legibility. > And do the same replacement for other magic numbers. After >

Re: [racket-users] Racket performance tips

On Monday, January 18, 2016 at 11:23:37 AM UTC-5, Brian Adkins wrote: > [...] > Thanks. Yes, I have a lot of cleanup to do - I basically hacked this together > as fast as I could to experiment. > > I had wondered about caching the soundex values in the past, so I just coded > up a version and

Re: [racket-users] Racket performance tips

My string-trim uses unsafe ops, but I'm pretty sure it's safe. The (safe) string-length at the start ensures we're using a string. The rest are indexing and fixnum arithmetic on integers that are guaranteed to be valid indices of the string. Still, if you don't like this, replace the unsafe

Re: [racket-users] Racket performance tips

However, I don't think string representation is the issue, so long as we're talking about the performance of string-trim. Racket's string-trim is written for flexibility. It allows you to trim the left side, the right side, or both sides of the string, and it allows you to trim characters

Re: [racket-users] Racket performance tips

On Sunday, January 17, 2016 at 10:09:36 AM UTC-5, Jon Zeppieri wrote: > Oops: that final else was wrong. If all we encounter in the string is > whitespace, the result is the empty string, not the input string, so: > > > ;; === > > (require racket/unsafe/ops) > > > (define (string-trim s) >  

Re: [racket-users] Racket performance tips

On Sunday, January 17, 2016 at 2:50:19 PM UTC-5, Brian Adkins wrote: > > With built-in string-trim, the lowest of three runs was 10293. Using your > string-trim the lowest of three runs was 7618, so it reduced the runtime by > 26%. Although, I probably should've mentioned that I'm not

Re: [racket-users] Racket performance tips

> On Jan 17, 2016, at 2:50 PM, Brian Adkins wrote: > > With built-in string-trim, the lowest of three runs was 10293. Using your > string-trim the lowest of three runs was 7618, so it reduced the runtime by > 26%. Would converting this into a `bytes-trim` function that

Re: [racket-users] Racket performance tips

MRI (the main ruby interpreter) has an odd string representation that's optimized for shorter strings. There's some info here: [ http://patshaughnessy.net/2012/1/4/never-create-ruby-strings-longer-than-23-characters]. The type is defined here: [

Re: [racket-users] Racket performance tips

Do we know if ruby represents strings the same way Racket does? The representation in C clearly admits more efficient implementations of relevant operations here, and Ruby's might too. Robby On Sun, Jan 17, 2016 at 2:00 PM, Jon Zeppieri wrote: > My string-trim uses unsafe

Re: [racket-users] Racket performance tips

On Sunday, January 17, 2016 at 2:54:39 PM UTC-5, Brian Adkins wrote: > On Sunday, January 17, 2016 at 2:50:19 PM UTC-5, Brian Adkins wrote: > > > > With built-in string-trim, the lowest of three runs was 10293. Using your > > string-trim the lowest of three runs was 7618, so it reduced the

Re: [racket-users] Racket performance tips

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

Re: [racket-users] Racket performance tips

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 >

Re: [racket-users] Racket performance tips

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

Re: [racket-users] Racket performance tips

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,

Re: [racket-users] Racket performance tips

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 >

Re: [racket-users] Racket performance tips

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!`,

Re: [racket-users] Racket performance tips

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: ;;