I didn't want to start a flame war, I just didn't want people being misled
into thinking static vars are a big perf improvement for most code. It's
better do use ordinary dynamic vars unless you're sure it will be
beneficial for some tight loop somewhere. The usual case is the JIT inlines
the v
I don't want to question your microbenchmarks, but I'm not sure you have
the correct interpretation.
Read memory fences have little to no cost. In particular, read memory
fences are a no-op (literally) on x86 unless the cache line is invalidated.
On Wednesday, August 6, 2014 5:54:32 AM UTC-5, R
Last sentence should be: "I've replaced vars with Java methods in some
high-performance cases and found a 0% speedup."
On Wednesday, August 6, 2014 5:54:32 AM UTC-5, Robin Heggelund Hansen wrote:
>
> Just read this blog post about Oxen (
> http://arrdem.com/2014/08/05/of_oxen,_carts_and_ordering/
It's worth pointing out that var indirection is already cheap in Java--it
is generally dominated by IO, memory access, object construction, dynamic
dispatch... The JIT compiler will inline any var access if the var doesn't
visibly change, and only needs to check one word of memory per var each
explanation.
>
> Regards
>
> Plínio
>
>
> On Fri, Jul 25, 2014 at 3:47 AM, Robin Heggelund Hansen <
> skinn...@gmail.com > wrote:
>
>> I was just looking for a OAuth library, this looks great!
>>
>> kl. 19:15:11 UTC+2 torsdag 24. juli 2014 skrev Mik
Qarth is a simple interface to OAuth. Qarth's goal is to fix the problem of
Ring/Compojure and/or Friend apps reinventing the wheel for OAuth.
Qarth features zero-effort Friend integration. The interactive auth flow in
"friendless" Qarth is two or three lines of code plus configuration. All
OAu
Is there a reason you want an (empty some-map-entry) to implment IMapEntry?
You can already do ordinary modifications on it where it loses the type.
Not sure why empty should be an exception. IMapEntry only provides key,
val, and java.util.Map.MapEntry, and probably if you're modifying map
entr
izing its
head.
On Monday, May 13, 2013 4:21:54 AM UTC-5, Meikel Brandmeyer (kotarak) wrote:
>
>
> 2013/5/13 Mike Thvedt >
>
>> A good implementation of ISeq won't return a new object, and new
>> short-lived objects are cheap on the JVM anyway. OTOH count can be
A good implementation of ISeq won't return a new object, and new
short-lived objects are cheap on the JVM anyway. OTOH count can be slow for
some data structures. if you don't like instantiating lots of new objects
only to throw them away, you're missing out on one of HotSpot's most
significant
ANN: Clearley 0.2.0
https://github.com/mthvedt/clearley
Yet another Clojure parser library.
Clearley is a parser for people who aren't interested in parsing, and just
want to get up and running as quickly as possible processing streams of
structured data.
Bullet points:
* No need to fool aro
10 matches
Mail list logo
