As a co-author of the reactive manifesto I'd like to point out that
"reactive" can be considered a superset of "async". Good reactive
applications are event driven and non-blocking. They are also responsive,
resilient, and scalable which async can help with but does not prescribe.
What are the
>
> In my personal experience I cannot get within 10X the throughput, or
>> latency, of mutable data models when using persistent data models.
>>
>
> Hi Martin,
> Thanks for finding this thread :-). Let me ask a reversed question. Given
> you come from a persistent data model where code remains
> As a co-author of the reactive manifesto I'd like to point out that
>> "reactive" can be considered a superset of "async". Good reactive
>> applications are event driven and non-blocking. They are also responsive,
>> resilient, and scalable which async can help with but does not prescribe.
>
>
>
>1. Due to the path-copy semantics, the contention gets driven to the
>root of the tree.
>
>
> Out of curiosity, would reference counting (rather than or in addition to
> "normal" GC) help with this? Or is reference counting problematic in a
> highly concurrent environment? It seem
Memory access patterns make a huge a difference to memory throughput. I've
explored this in some detail in the following blog.
http://mechanical-sympathy.blogspot.co.uk/2012/08/memory-access-patterns-are-important.html
On Sunday, 30 March 2014 06:40:24 UTC+1, Andy C wrote:
>
>
> Hi,
>
> So this
