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 matching an arbitrary regexp. Ruby's String#strip, on the other hand, trims whitespace characters from both sides of the string. If you want to trim only the left side, you use String#lstrip. The right side? String#rstrip. (And then there are in-place and non-mutating versions of each.) If you want to trim something other than whitespace you use something else. My string-trim is much faster than Racket's built-in one, because it's completely inflexible, like Ruby's String#strip. Also, because it doesn't use regexps, it doesn't have another layer of interpretation -- and the whole thing is visible to the JIT (though I don't know how much difference that makes in this case). -Jon On Sun, Jan 17, 2016 at 3:08 PM, Robby Findler <ro...@eecs.northwestern.edu> wrote: > 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 <zeppi...@gmail.com> wrote: > > 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 ops with the > corresponding safe ones. It will still be much faster than the built-in > version. > > > >> On Jan 17, 2016, at 2:54 PM, Brian Adkins <lojicdot...@gmail.com> > 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 > runtime by 26%. > >> > >> Although, I probably should've mentioned that I'm not particularly > interested in unsafe optimizations. I already have a very fast C program if > I'm willing to risk unsafe behavior, so for Racket, I'd like to retain > safety. > >> > >> Having said that, I'm pretty sure a combination of using Byte Strings > and manually optimizing string-trim & string-replace (or skipping them in > some cases) will get under the Ruby time. > >> > >> -- > >> 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. > -- 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.
