EcoConception Logicielle

This is all fairly fresh in my mind, because I discovered a snippet of code somewhere (not disclosing where, as I'm doing the responsible thing and doing the disclosure properly), that was along the lines of:

var jsonData = eval ("(" + string + ")");

Apparently, JSON.parse() isn't good enough for them. 

Horrifying.

En PHP lorsque l'on souhaite passer des arguments par référence, nous utiliserons le caractère &. Soit pour dire « A est une référence vers la valeur de B » :

$A =& $B;

Attention, si vous provenez du monde du C, ne confondez pas les références enPHP et les pointeurs que vous pourrez trouver en C. Il s'agit juste ici de pouvoir appeler une valeur identique avec des noms différents.

Une référence s'utilise ensuite comme n'importe quelle variable. Vous pouvez par exemple utilisez la fonction unset($ref) pour détruire votre référence.

Néanmoins, même s'il est très facile de détruire une référence, il deviendra plus complexe de supprimer la valeur stockée en mémoire. C'est pourquoi, la manipulation des références est un des points critique concernant la consommation en ressources mémoire d'un script.

When non-functional requirements, such as performance and availability, are critical to success, I’ve found the most important thing is to get the model correct for the domain at all levels.   That is, take the principles of DDD and make sure your code is an appropriate reflection of each domain.  Be that the domain of business applications, or the domain of interactions with infrastructure, I’ve found modelling is everything.

Let's start putting the problem in context with some examples.  Our hardware tries to hide the main-memory latency via a number of techniques.  Basically three major bets are taken on memory access patterns:

(...)

Conclusion

To achieve great performance it is important to have sympathy for the cache sub-systems.  We have seen in this article what can be achieved by accessing memory in patterns which work with, rather than against, these caches.  When designing algorithms and data structures, it is now vitally important to consider cache-misses, probably even more so than counting steps in the algorithm.  

If you are willing to do some C style programming for large datasets it is possible to control the memory layout in Java by going off-heap.  If you do, the benefits in performance, compactness, and avoiding GC issues are significant.  However this is an approach that should not be used for all applications.  Its benefits are only noticable for very large datasets, or the extremes of performance in throughput and/or latency. 

There is a significant difference in performance for the different means of doing sequential file IO from Java.  Not all methods are even remotely equal.  For most IO I've found the use of ByteBuffers and Channels to be the best optimised parts of the IO libraries.  If buffered streams are your IO libraries of choice, then it is worth branching out and and getting familiar with the implementations of Channel and Buffer or even falling back and using the good old RandomAccessFile.

Summary

If a system is decomposed into components that keep their own relevant state model, without a central shared model, and all communication is achieved via message passing then you have a system without contention naturally.  This type of system obeys the single writer principle if the messaging passing sub-system is not implemented as queues.  If you cannot move straight to a model like this, but are finding scalability issues related to contention, then start by asking the question, “How do I change this code to preserve the Single Writer Principle and thus avoid the contention?”

The Single Writer Principle is that for any item of data, or resource, that item of data should be owned by a single execution context for all mutations.

In conclusion it is possible to achieve the same native C/C++ like levels of performance in Java for serialising an object to-and-from a byte stream by effectively using the same techniques.  The UnsafeMemory class, for which I've provided a skeleton implementation, could easily be expanded to encapsulate this behaviour and thus protect oneself from many of the potential issues when dealing with such a sharp tool.

Now for the burning question.  Would it not be so much better if Java offered an alternative Marshallable interface toSerializable by offering natively what I've effectively done with Unsafe???