The code is available at this URL: http://code.google.com/p/bwhf/
(look at the hu.becliza.andras.bwhf.control.[BinRepParser,
BinReplayUnpacker] files)
It is definitely not as dynamic, which helps quite a lot, but I wanted
to have something high level and declarative.
Thank you for your help, I'll look into the improvements you
suggested.
Vincent.
On Mar 21, 9:40 am, Christophe Grand <christo...@cgrand.net> wrote:
> Hello,
>
> Is the java code online somewhere to compare? (Since your code is an
> interpreter for byte-fields specs there's a lot of stuff going to read a
> single byte, I wonder if the java code you're benchmarking against is
> that dynamic)
>
> Right now, null-string and read-field-aux are the most time consuming
> functions.
>
> Creating a cons for each byte read is too much overhead, I rewrote
> null-string like this (yes it's lower level):
> (defn null-string
> "Read a nul-terminated string. Stop at \\0 or at length n
> whichever comes first."
> [#^ByteBuffer buf n]
> (let [arr #^"[B" (make-array Byte/TYPE n)
> sb (StringBuilder.)]
> (.get buf arr)
> (areduce arr i append true
> (when append
> (let [b (aget arr i)]
> (when-not (zero? (int b))
> (.append sb (char b))))))))
>
> Concerning read-field-aux I rewrote it like that:
> (def read-field-aux
> (let [getters {Byte get-byte
> Short get-short
> Integer get-integer}]
> (fn [#^ByteBuffer buf n type]
> (let [f (getters type)]
> (if (== (int n) 1)
> (f buf)
> (let [arr (make-array Object n)]
> (dotimes [i n]
> (aset arr i (f buf)))
> (vec arr)))))))
>
> closing over getters (rather than rebuilding it inside the closure)
> yielded nearly as much as going "lower level".
>
> With these two changes, it's the dispatch fn that now dominates.
>
> Vincent Foley a écrit :
>
>
>
> > Here:http://gist.github.com/82352
>
> > I have posted memory and cpu profiling figures.
>
> > On Mar 20, 6:56 am, Christophe Grand <christo...@cgrand.net> wrote:
>
> >> Hello Vincent,
>
> >> Vincent Foley a écrit :
>
> >>> Hello,
>
> >>> For the past few days, I've been trying, unsuccessfully, to make an
> >>> application I wrote faster. A Java program that performs, more or
> >>> less, the same task takes 12 seconds (on my machine) to parse 1000
> >>> files; my Clojure program takes nearly 3 minutes. This more than an
> >>> order of magnitude slower! Using the profiling tools available with
> >>> the JVM, I quickly determined which function was the costliest. I
> >>> copied it into a simple script file to profile it in isolation. I
> >>> have made the script and the profile results (long!) available at this
> >>> URL:http://gist.github.com/82136
>
> >> On my box nearly one half of the total time is sepent in the building of
> >> arr (and by looking at your profiling data a good chunk of these traces
> >> are related to this map call).
> >> Better to get it out of the loop.
>
> >> (let [arr (into-array Byte/TYPE (map byte [7 ; 1 Byte
> >> 3 0 97 0 98 0 99 ; 3 Shorts
> >> 0 0 100 100 ; 1 Integer
> >> 65 66 67 68 69 70 71 72 73 74
> >> ; 10 String
> >> 0 0 0 0 0 0 0 0 0 0 ; 10 ignored
> >> ]))
> >> buf (ByteBuffer/wrap arr)]
> >> (time
> >> (dotimes [_ 10000]
> >> (.position buf 0)
> >> (run buf))))
>
> >> Can you give the profile results for this code?
>
> >> Christophe
>
> >> --
> >> Professional:http://cgrand.net/(fr)
> >> On Clojure:http://clj-me.blogspot.com/(en)
>
> --
> Professional:http://cgrand.net/(fr)
> On Clojure:http://clj-me.blogspot.com/(en)
--~--~---------~--~----~------------~-------~--~----~
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
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
-~----------~----~----~----~------~----~------~--~---
