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
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
= *(def r
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)
On Feb 3, 12:54 pm, Curtis Gagliardi gagliardi.cur...@gmail.com
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
On Sun, Feb 3, 2013 at 2:42 AM, Shantanu Kumar kumar.shant...@gmail.comwrote:
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
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,
On Feb 3, 3:54 pm, Shen, Feng shen...@gmail.com 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
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
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,
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
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
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
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 to
On Feb 3, 2013 4:40 AM, john john.vie...@gmail.com 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,
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
shaved
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
@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
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.
According to
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 john.vie...@gmail.com 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
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
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
On Feb 3, 11:40 pm, Alexandros Bantis amban...@gmail.com 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
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 one
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.
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
works for me:
= (*let [^java.io.BufferedReader a
(clojure.java.io/readerc:\\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 warning,
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
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
