Re: clojure.contrib.base64
What about compared to the library I listed in the OP? On Oct 10, 8:37 pm, Alexander Taggart m...@ataggart.ca wrote: I see about a 50% increased throughput over apache commons-codec as well. I use the perf-base64 ns generate input data and output timing files to keep track of changes to the performance over time, lest a regression creep in. I'll add some documentation if you want to play with it. -- 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
clojure.contrib.base64
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? -- 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
Re: Exception handling changes in Clojure 1.3.0
On Oct 3, 9:27 pm, Stuart Halloway stuart.hallo...@gmail.com wrote: Catching checked exceptions seems to work fine. Try e.g. (try (throw (java.io.IOException.)) (catch java.io.IOException _ caught!)) I suspect something else is going wrong in the GAE example. Can you narrow the code down to a block you can quote in full here? Stu Stuart Halloway Clojure/corehttp://clojure.com Does this work across function boundaries? (try (exception-throwing-fn 1 2 3) (catch java.io.IOException _ caught!)) -- 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
Re: clojure.contrib.base64
Sure, I can use that file. This DIY attitude doesn't benefit the beginners. I can add and use that java, but 90% of clojure users will use the clojure contrib function and 9% will use faster sun encoder, because people don't know that Sun's implementations are slow and that better ones are available. I see little reason for not making these implementations default, rather than requiring the user to know about existence of obscure libraries, in java no less. On Oct 6, 1:50 pm, Meikel Brandmeyer (kotarak) m...@kotka.de wrote: Hi, may I ask an heretic question? When there is a fast migbase64... why not just use that one? It was always promoted to use existing Java libraries where it made sense. Or is clojurescript now changing this stance? Sincerely Meikel -- 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
