This actually introduces an opportunity for a much larger set of utilities.
clojure.data.crypto base64 is part of this idea anyways, and putting it in place along with nice wrappers around the messy java crypto bits I think could provide a significant win. I have had to do this several times now and it would be great to have in the future. The thing that always pushed me away was relying on sun.misc when all of the jdks don't have it. Cheers, Aaron Bedra -- Clojure/core http://clojure.com On 10/06/2011 08:07 AM, Stuart Halloway wrote: >> I use Base64 encoding a lot and the slow implementation is hurting a >> lot. It's slower than Sun misc encoder/decoder >> and that one is very very slow. I was using Sun's implementation a bit >> and it took 80 seconds to encode a 56 MB file. >> Then I found this: http://migbase64.sourceforge.net/ >> It loaded from a disk drive and encoded the same file in 0.3 seconds! >> Would it be possible to have Clojure contrib use an implementation >> like this and thus enable all Clojure developers to have lightning >> fast Base64 encoding/decoding? I know having everything implemented in >> clojure is a big thing around here but in case of Base64 encoding and >> regular expressions I think the language would benefit greatly by >> having implementations which are orders of magnitude faster than >> default implementations in java. Did I say regular expressions? >> http://www.tusker.org/regex/regex_benchmark.html >> Like Rich Hickey said: why should we reinvent file streams and sockets >> in each language? >> I think the same principle applies to Base64 and regular expressions, >> especially when in Clojure we have an opportunity to replace standard >> java implementations with ones that are orders of magnitude faster. >> What are your views on this? > I too would like a fast base64. There are a few different things we could do: > > 1. Vet the best Java one and link it from contrib.base64 (and possibly > deprecate the contrib as well). > > 2. Approve a base64 lib for inclusion by reference in contribs. > > 3. Write a fast clojure one (possibly a direct port of the project you link, > if it is the best). > > I have several Clojure projects that ship with no binary dependencies. This > is a maintenance virtue, which is why I think #3 is important. > > If somebody writes a good one I will fast track getting it into contrib. > > Stu > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
