Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Karol Swietlicki <magotari@gm...> - 2009-12-29 06:54:15
I needed STRING= to be a bit faster in my code, so I did a bit of
optimizing around and I have some good results.
We seem to assume that :start and :end are given. This ends up
requiring two indices to manage in the comparison loop. However,
without the keyword args we can do without that and one index will
Secondly, we do either one or two full calls each time we want to use
STRING=. This is not necessary, a much reduced version of
sb-impl::%sp-string-compare can be inlined to avoid having to do that.
Overall I am very happy with the numbers that I am getting on the
benchmarks, even without inlining this is an improvement. In the best
case with the inlining I got about 50% speedup, although it would
probably grow with the length of the strings being compared.
In a couple of days I will have a patch, provided there is interest.
I'd like to ask if someone else is already working on this and if what
I'm saying has any merit. We don't want fast code if it returns bad
results after all.
Here is my reduced version of sb-impl::%sp-string-compare. This should
be more suitable to inline than the full version. Comments are
(defun %qsp-string-compare (str1 str2)
(declare (type simple-string str1 str2))
(let ((len1 (length str1))
(len2 (length str2)))
(if (/= len1 len2)
(do ((index 0 (1+ index)))
((= index len1) t)
(if (char/= (schar str1 index)
(schar str2 index))
On Tue, Dec 29, 2009 at 12:53 AM, Karol Swietlicki <magotari@...> wrote:
> I needed STRING= to be a bit faster in my code, so I did a bit of
> optimizing around and I have some good results.
> In a couple of days I will have a patch, provided there is interest.
> I'd like to ask if someone else is already working on this and if what
> I'm saying has any merit. We don't want fast code if it returns bad
> results after all.
I spent a bit of time poking around in this area, but I only tried
specializing the innter loops of %SP-STRING-COMPARE to avoid
BASE-STRING/STRING checking. I don't think there's anybody else
working here and improvements would be welcome. Please send a patch
when you feel it's complete.