I don't think this particular example relates.
Memoize produces a function, so the time spent is really about hashing
functions which presumably hashes on the address of the function (or
something similar) and never touches the underlying record.
In the later example, you are mostly timing the cos
ah I see, you're right , which made me think why would memoize allow
non-func but then I realized this:
=> *((memoize {:key 1}) :key)*
1
=>* ((memoize {:key 1}) :ke)*
nil
this is what I thought I was doing:
=> *(def g (A. "a" 3))*
#'runtime.q_test/g
=> *(defn f [] g)*
#'runtime.q_test/f
=> *(de
Hi,
the library
https://github.com/straszheimjeffrey/dataflow
and
http://richhickey.github.com/clojure-contrib/dataflow-api.html (1)
or
https://github.com/gcv/dgraph
seems to me very cool for systems that need to react on changes on
dependent values. I very much like the API in (1)
Actually
On Feb 3, 12:54 pm, Curtis Gagliardi
wrote:
> I took your version Feng and used rem instead of mod and added a type hint
> and got down from:
> 23217.321626 => 11398.389942
>
> No idea where to go from here though. I'm surprised there's such a
> difference even not using any sort of collection.
On Sun, Feb 3, 2013 at 2:42 AM, Shantanu Kumar wrote:
> I was able to shave off some more by writing (not= 0 (rem i d)) as (<
> 0 (rem i d)).
>
Haven't tested, but based on past experience I would expect (not (zero?
(rem i d))) to be the fastest way, or possibly
(pos? (rem i d))
In general, zer
> I was able to shave off some more by writing (not= 0 (rem i d)) as (<
0 (rem i d)).
the running time is about 4787ms on my computer, compare to *2759ms *of the
java version, a bit slower, but not much.
沈锋
美味书签 : http://meiweisq.com
博客： http://shenfeng.me
On Sun, Feb 3, 2013 at 6:42 PM, Shant
On Feb 3, 3:54 pm, "Shen, Feng" wrote:
> > I was able to shave off some more by writing (not= 0 (rem i d)) as (<
>
> 0 (rem i d)).
>
> the running time is about 4787ms on my computer, compare to *2759ms *of the
> java version, a bit slower, but not much.
>
> 沈锋
> 美味书签 :http://meiweisq.com
> 博客：h
Given that I don't know much about how scala does optimizations, I find the
question of why the scala version is faster than the Java version even more
interesting.
It seems to me that in Scala, the list (don't know the actual data type
which is created) of 1 to 20 is created each time isDivisi
> Changing (< 0 ...) to (pos? ..) had no noticeable delay.
I meant 'difference', not 'delay'.
Shantanu
--
--
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
Thank you for this(I'm now looking into dgraph), I am very interested in
such things, though you should look at me like a I'm a newbie in both this
and clojure. Whatever I end up doing will unavoidable use such concepts:
graph, dependencies... I imagine that a properly implemented system like
so, w
The Scala version is probably faster because it uses a range (1 to top)
which is represented as a pair of integers (the start and endpoint).
Perhaps the JVM can even eliminate that completely with escape analysis.
The Java version is repeatedly filling an ArrayList with the numbers in
that rang
Quick anecdote: I've got an HTTP Kit server running in a test environment
and the initial results are *very* promising. It's handling a mix of sync,
async, and WebSocket requests and so far has been a pleasure to use.
HTTP Kit's sweet spot seems to be quite large too: folks running
high-traffic
without looking at the code:
ranges in scala have been optimized in i think 2.10 to be able to be
inlineable completely when you iterate over them. at runtime, it
*should* be equal to a simple while loop and a counter variable
Am 03.02.2013 14:28, schrieb Jules:
> The Scala version is probably fas
If your goal is just to make it fast, then you should use a different
algorithm, e.g.
(defn bump-up
"Bump up n by a multiple of x until greater than or equal to k."
[n x k]
(if (>= n k) n (recur (+ n x) x k)))
(defn bump-up-fast
"Bump up n by a multiple of x until greater than or equal
On Feb 3, 2013 4:40 AM, "john" wrote:
> seems to me very cool for systems that need to react on changes on
dependent values. I very much like the API in (1)
>
> Actually my personal opinion is that this is a very substantial thing in
business applications.
In such an application, I found more use
>>For some reason, by splitting out the inner loop into a function
>>shaved 6 more seconds (from 34s to 28s) on my low-config 32-bit
>>laptop:
Pulling every-d? out into it's own function slowed things down a few
seconds for me. Strange stuff.
--
--
You received this message because you are
Was on clojure 1.4, just tried on 1.5.0-RC4 and its a few hundred
miliseconds faster in its own
function.
4921.78197 msecs vs 5251.267893 msecs
On Sunday, February 3, 2013 11:52:11 AM UTC-6, Curtis Gagliardi wrote:
>
> >>For some reason, by splitting out the inner loop into a function
> >>s
yes, I believe I can just make a list of the greatest common factors and
then multiply them out to get the number rather than iterating through 2
through n. Still, I'm curious about the performance difference, since
all three are running on the same JVM and ultimately are all compiled
down to j
@stephan thank you for your info.
so if I understand you correctly you use
https://github.com/fogus/bacwn/blob/master/src/clojure/fogus/datalog/bacwn/impl/graph.clj
to build a dependency tree of your data and then query this tree to find
the dependent values(cells) that need updates.
Am Sonntag
Hey guys,
I'm trying to read a lot of data, sometimes from *in* and sometimes from a
file. I extensively use the native .write and .read java methods.
According to the clojure doc for reader, it says that "Default
implementations always return a BufferedReader". However, when I write,
(*defn*
Why not add type hints like this ?
(let [^java.io.BufferedReader in
^java.io.BufferedWriter out ...]
..
Luc P.
> Hey guys,
>
> I'm trying to read a lot of data, sometimes from *in* and sometimes from a
> file. I extensively use the native .write and .read java methods.
>
> Accordi
Unfortunately it doesn't work.
Reflection warning, NO_SOURCE_PATH:20 - call to write can't be resolved.
Reflection warning, NO_SOURCE_PATH:21 - reference to field newLine can't be
resolved.
On Sunday, February 3, 2013 2:35:23 PM UTC-5, Luc wrote:
>
> Why not add type hints like this ?
>
> (let
On Feb 3, 2013 1:42 PM, "john" wrote:
> so if I understand you correctly you use
https://github.com/fogus/bacwn/blob/master/src/clojure/fogus/datalog/bacwn/impl/graph.clj
> to build a dependency tree of your data and then query this tree to find
the dependent values(cells) that need updates.
Yes.
Can you post a larger chunk of code for us to examine, perhaps on github or as
a gist if it is over 30 lines of code or so? Many of us have had good success
with eliminating reflection using type hints, so it should be possible to make
it work.
Andy
On Feb 3, 2013, at 12:50 PM, Kanwei Li wrot
Hi,
Is there a straightforward way to invoke an editor within clojure e.g.
(clojure.java.shell/sh "emacs" some-file)?
I've taken a look at popular shell libraries like conch and stevedore but
found nothing helpful.
If you're curious why I want to do it, it's to open a lein dependency in
emacs f
On Feb 3, 11:40 pm, Alexandros Bantis wrote:
> yes, I believe I can just make a list of the greatest common factors and
> then multiply them out to get the number rather than iterating through 2
> through n. Still, I'm curious about the performance difference, since
> all three are running on th
I was able to open an X windows emacs session using:
(require '[clojure.java.shell :as sh])
(sh/sh "emacs")
on my system. The REPL did not give another prompt until I quit that emacs
invocation. I was able to get another REPL prompt immediately using this:
(future (sh/sh "emacs"))
On Sunday, February 3, 2013 1:07:41 AM UTC-5, puzzler wrote:
>
> I just went through the process of converting my map-based program over to
> records, hoping it would improve speed. Much to my dismay, it actually
> slowed my program down substantially. With some profiling, I discovered
> that
In these examples, the map/record is freshly created each time through the
loop, so caching should not be a factor.
In fact, later in the thread, AtKaaZ posted an example which demonstrated
his timing results when computing the hash repeatedly on the same object.
Oddly, the performance of hashing
Yes, the Clojure 1.3 doc is wrong. As a new Clojure user, I was pretty
confused for a while.
But after reading this thread I still don't understand why the map behavior
(where 3 and 3.0 are considered different map keys) wasn't considered
incorrect, rather than the = behavior.
http://clojure.
John,
Thanks for your email and the links, I'm interested in this topic and wasn't
aware of the previous work you referenced.
I would't be surprised if the sentiments expressed by Stephen Compall in this
thread, specially
> my Clojure style seeks immutable solutions, and cells-ishs don't fi
works for me:
=> (*let [^java.io.BufferedReader a
(clojure.java.io/reader"c:\\windows\\setupact.log")] (println (. a
readLine)))
*
AudMig: No audio endpoint migration settings found 0x2
nil
=> *(let [a (clojure.java.io/reader "c:\\windows\\setupact.log")] (println
(. a readLine)))*
Reflection warn
There has been some discussion of lazily computed expressions in the
Numerical Clojure group:
https://groups.google.com/forum/?fromgroups=#!forum/numerical-clojure
There, the interest is really in deferring execution of large matrix
operations until and efficient execution strategy can be deter
Hi,
I'm trying to create Excel files with jexcelapi:
https://sourceforge.net/projects/jexcelapi/files/jexcelapi
API provides a method of creating Excel fonts which uses instances of a
non-public inner class:
public WritableFont(FontName fn,
int ps,
34 matches
Mail list logo
