[SP-pm] Quando alguém disser que Java é melhor que Perl:

Stanislaw Pusep creaktive at gmail.com
Wed Nov 10 04:38:39 PST 2010


JVM do Mac foi descontinuada.
Mas vamos lá. SQL Developer é uma IDE para banco de dados do Oracle.
HeidiSQL, que eu estava rodando simultaneamente no Windows, é uma IDE para o
MySQL. Descartando todas as camadas de abstração entre a interface com o
usuário e o processador, são *essencialmente a mesma coisa*. Por isso, tomei
a liberdade de compará-los :)
HeidiSQL foi implementado em Object Pascal, p/Windows. *SE* eu rodasse ambos
em Windows, HeidiSQL teria muito menos camadas de abstração, e, ainda assim,
ofereceria funcionalidade similar. Logo, SQL Developer sofre de bloat. Seria
generalizar demais dizer que qualquer coisa feita em Java sofre de bloat.
Entretanto... Vide as evidências :)

ABS()



2010/11/10 Alexei Znamensky <russoz em gmail.com>

> 2010/11/10 Stanislaw Pusep <creaktive em gmail.com>
>
> Vou contar uma estorinha bem curta. Fato verídico. Outro dia, me peguei
>> rodando um SQL Developer, que é da Oracle, feito em Java, que roda numa VM
>> da Oracle. Paralelamente, estava rodando um VirtualBox, também da Oracle,
>> rodando um Windows XP, também em VM.
>> Observei que o processo do Java estava consumindo mais ciclos de CPU e
>> mais RAM do que o VirtualBox. Como assim, um OS inteirinho, sem ser dos
>> melhores, "pesando" menos do que um aplicativo ridículo de uso bem
>> específico?!?!
>>
>
> Virtual Machines (onde Java Virtual Machines = JVM):
>
> Virtualbox tem módulo no kernel e atua também em kernel-space. O VMWare
> também faz isso. Qualquer solução de virtualização que queira competir em
> maior escala, no mercado corporativo, precisa atuar mais perto do hardware
> para ter uma resposta mais rápida.
>
>
> Quase todas as JVMs  (acredito que a do Mac seja a exceção mais notável)
> executam exclusivamente em user-space. A do Mac foi feita pela própria Apple
> e é integrada no kernel do SO. Diz a lenda (não tenho um Mac, alguém quer
> fazer uma doação?) que a JVM do Mac é sensivelmente mais rápida que a de
> outros sistemas operacionais. Existem várias implementações diferentes de
> JVM disponíveis (Sun, OpenJDK, IBM, ...), e cada uma delas tem seu conjunto
> de flags de tuning que podem ser aplicados.
>
>
> Memória:
>
> Todas as JVMs têm um limite máximo de memória dinâmica que elas podem
> alocar, um setting chamado Maximum Heap Size. O default não é alto, mas cada
> aplicação passa o valor que quiser na linha de comando, e isso é usualmente
> passado sim, para garantir que as aplicações não estourem o limite (quando
> isso acontece a JVM dá crash). Logo, não é a JVM que precisa de mais memória
> que o seu VirtualBox, por si só: é a aplicação, específica, que você está
> executando, que precisa de muita memória.
>
> CPU:
>
> Um SO inteiro, na VM, se estiver em 99% de idle, irá consumir menos CPU que
> qualquer aplicação nativa que esteja fazendo *alguma* coisa. Agora, se o
> "aplicativo ridículo de uso bem específico" que você está usando fica
> fazendo algo por baixo dos panos o tempo inteiro, eu sugiro que você use
> algum outro aplicativo que resolva o seu problema e que não faça isso.
> Infelizmente eu não conheço o SQL Developer da Oracle, nem trabalho com
> desenvolvimento há um bom tempo, não tenho como oferecer outra opção para
> você.
>
>
> De novo: não estou aqui (aqui!!!) para defender Java. Mas, não é com
> informações imprecisas e/ou incompletas que nós vamos nos mostrar melhores.
> Isso, na minha humilde opinião, é mais um desserviço à comunidade Perl do
> que uma ajuda.
>
> []s,
> --
> Alexei Znamensky [russoz_gmail_com] [russoz.wordpress.com] [
> www.flickr.com/photos/alexeiz]
> «Only love / Can bring the rain / That makes you yearn to the sky»
>
>
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm em pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20101110/c27dfe5c/attachment-0001.html>


More information about the SaoPaulo-pm mailing list