Dieval Guizelini:
Eu tomaria muito cuidado com os testes de garagem e algoritmos “alternativos”…
Existe uma razão para a API ser mais lenta na cópia do Array, entre elas:
- controle dos limites
- thread-safe
- gerenciamento de memória (rsrs)
E um exemplo de algo parecido na SUN:
http://java.sun.com/docs/books/performance/1st_edition/html/JPNativeCode.fm.html
fw
Mas isso é obvio, o que tornaria essa mesma inviável em aplicações que exigem performance, como como captura de vídeo. Como contornar esse problema, se você não possui opção(JMF é horrível para aplicações robustas e dsj não é opensource, nem free)? O que quero dizer?
Quero dizer que a classe Unsafe torna possível contornar alguns inconvenientes do coletor de lixo
EX:
Uma aplicação que precisa capturar vídeo de uma placa e exibí-lo de alguma forma. A parte crítica de uma aplicação como essa está justamente na hora de copiar os bytes de uma área da memória cedida pela placa de captura, para a sua imagem, e depois pinta-la em um contexto gráfico, como graphics 2d. Eis o frame rate.
Com o coletor de lixo trabalhando descontroladamente(não se tem controle do GC), esse tipo de aplicação congela a todo instante, na plataforma java.
Outro uso para isso seria resolver o problema do cacheiro viajante em tempo hábil. Imagina se um sistema de navegação automática, de um avião, tivesse que congelar alguns segundos, por causa do coletor de lixo, ou porque System.arrayCopy perde tempo em checar n coisas desnecessárias, para deixar sua execução “segura”(segura entre aspas. Se sabe muito bem que uma exceção como IndexOutOfBound danifica toda área do programa, na máquina virtual) ?
O vini godoy e eu vinhamos conversando sobre isso já a algum tempo, e sobre poder usar esse tipo de artifício, quando necessário, como em c#. Essa classe torna isso possível.
