| Age | Commit message (Collapse) | Author |
|---|
|
Not essential, and the code already handled this.
|
|
|
|
Without these, we are doomed to have CPS calls to those procedures.
|
|
|
|
Otherwise, it'll be a bit awkward if we do have something more useful
to return. And we wouldn't be able to get at the slset's list so
easily.
|
|
Do not count list construction towards benchmark time.
This doesn't appear to make a big difference but it's good to pull
that out of the calculation.
|
|
|
|
Not strictly needed, but could be helpful and completes the
operations. Also, if we ever reimplement it using some other
strategy, this might be more useful.
|
|
|
|
Add a test to ensure this won't happen again.
|
|
The original implementation just diffed the same set with itself,
and needed a workaround for srfi-1's shortcut on the identical list.
Since we're comparing to other implementations with differing sets, it
makes sense to do the same here.
We actually started doing this but ended up just redefining the same
list...
|
|
Ruby is about the same speed as slets. Clojure (babashka) and Python
are goddamn fast. Python is 10 times as fast. Clojure is twice as
slow as Python but that still outperforms Ruby and slsets.
|
|
Doesn't do that much, but it's a good idea for slsets as well because
it makes it unlikely that plist changes are ever observed, because
there's no thread switching.
|
|
This uses hash-tables directly instead of creating the hash table from
the lset every time. It's faster than using srfi-69 because it can be
inlined better.
|
|
Makes a bit of an impact - about 20% faster
|
|
This implements sets of symbols *as lists*, like in the srfi-1 lset
operations. It maintains the benefit of using lists for everything,
but not having to pay the quadratic performance penalty that srfi-1
entails. We achieve this by using plist operations to "mark" items
so we have to visit the list "set" only a fixed number of times.
|
