http://www.javalobby.org/java/forums/t72230.html)... I think that all this "Java is Slow" is a myth from the early JDK 1.0/1.1...
What? Doesn't like swing? So, give Eclipse's SWT a look: http://www.eclipse.org/swt/widgets/
On the other hand, the language is very simple to understand, all good design patterns are simple to implement, the code is more reusable and even there is the possibility of program with python (Jython http://www.jython.org/), tcl-java (http://tcljava.sourceforge.net/docs/website/index.html), groovy ( http://groovy.codehaus.com), _javascript_ (http://www.mozilla.org/rhino/) and, well.. pick one: http://www.robert-tolksdorf.de/vmlanguages.html
All language implementations for the jvm can access all java libraries and can make standalone programs as well...
Now that java will eventually become opensource ( http://www.vnunet.com/vnunet/news/2156205/sun-promises-open-source-java), maybe even with GPL (http://www.javalobby.org/java/forums/t73163.html) I see no reason to even the gnu/zealots complain about the java trap...
Sorry for being so boring with all these links... and I'm not saying that Java is the best for amsn development :)
On 6/1/06, Youness Alaoui <
[EMAIL PROTECTED]> wrote:
yeah, we can find some interesting benchmarks on the net, you just need to
google for it...
I was looking for one site with many detailed benchmarks for many
different programs (even Tcl/python/perl/COBOL) with the program that it
was tested on available...
I can't find it anymore, but I found this one :
http://shootout.alioth.debian.org/
this looks similar enough... but the results are different from the ones I
was expecting, maybe false positives, or false negatives in here... can't
tell who is right, but I definitely remember that it showed java a lot
slower, but with JIT, a bit faster...
why faster, because on huge programs, you always allocate a lot of memory,
and you can test, we even had a performance issue with some program (don't
know if it was amsn related or for my job) where the whole performance
issue was caused by many malloc/free calls... which means memory
allocation is VERY slow... the reason is that the OS needs to scan through
the memory slots and try to find an adequate memory slot for the requested
size, and using a complex algorithm for optimizing the memory used and
minimize fragmentation.
In java, the memory is allocated only once, and on the stack, so everytime
you allocate some memory, it's as simple as a 'sub esp, $size', so no more
malloc algorithm involved, no more hash table/linked list for storing the
heap pointers (needed so that the 'free' call will know how much memory
was allocated and thus needs to be freed). This memory management system
used in java allows for this speed optimization. apart from that, most of
the things you do is done by using the java API, and their library is
reallly GREAT (the best ever, noone will say the opposite), and that code
is native and optimized, in C, there are a LOT of bad programming
practices and a lot of hacked code, and a lot of custom made code that
aren't as optimized as a well tested and optimized common library (I'm
talking here in practice, not in benchmarking).
Also, note, that when I said that java was faster, I was thinking that
because at the time I compared the different languages, I was looking (for
my job) at the best solution, the most time-optimal solution for a regexp
engine, and I must say, the java regexp engine is the fastest, and IIRC,
it's even faster than perl's (although I found in the java regexp engine
many bugs that make it not match for a matching regexp, but it only
happens for REALLY COMPLICATED regexps (around 500 characters in the
regular _expression_)). So Java was from far, the best in this case, but I
also found out it was faster (a little bit) than C for computations only,
but the GUI, with its event loop, event system, was the slowest thing
ever...
anyways, I'll stop talking now.. or we'll never finish.
KKRT
On Thu, 01 Jun 2006 18:07:08 -0400, Bruno Costa <[EMAIL PROTECTED]> wrote:
> Benchmarks and articles here ya go! (now I'll be killed)
>
> http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
> http://www.javalobby.org/articles/swing_slow/index.jsp
>
> Java Hotspot: http://en.wikipedia.org/wiki/HotSpot
> Adaptive optimization: http://en.wikipedia.org/wiki/Adaptive_optimization
>
> http://www.javaworld.com/jw-02-1998/jw-02-jperf.html
>
> Note that these articles are relatively old, java today is even faster.
> Of course, I understand that a VM and the OO concepts introduces some
> overhead, but tcl, ruby, python, perl, c# all these languages are slower
> or
> as fast as java, but noone seems to be saying it all time :)
>
> On 6/1/06, Harry Vennik <[EMAIL PROTECTED]> wrote:
>>
>> Yes, you may be right, be we also need to think about what we are going
>> to
>> do
>> ourselves. For that I think there is just:
>> - Tcl because we use that now, and we all know it
>> - C because it is the best programming language that compiles to native
>> code
>>
>> I prefer C.
>>
>> I've always disliked interpreted languages because of their lack of
>> speed.
>>
>> And Youness: Java is faster than C for processing???? Benchmarks please
>> :-P
>>
>> Harry
>>
>>
>> Op donderdag 1 juni 2006 22:17, schreef Philippe Valembois - Phil:
>> > I think you misread the mail...
>> > He says that if we do a backend for Telepathy, he will create its own
>> GUI
>> > with Java... He doesn't ask anything... (Maybe he asks for the backend
>> :p)
>> > Phil
>> >
>> > Le Thursday 01 June 2006 21:51, Youness Alaoui a écrit:
>> > > Why are people asking for what they like, and not thinking about
>> what
>> is
>> > > right...
>> > > Yes, java development is really nice and fast! but java still has a
>> lot
>> > > of disadvantages for such a project, first, people hate it (:P), the
>> JVM
>> > > must be installed and is huge to download, so it's sad for dialup
>> people.
>> > > and yes, java is fast, it's even faster than C (really!) for
>> processing,
>> > > but the whole GUI part of Java is SLOW AS HELL, and yes, it is...
>> > > also, please don't talk about that mercury crap :p
>> > > I'm trying to think about what would be the most beneficial for all
>> of
>> > > us, as developers and for our users. So java is not the perfect
>> solution
>> > > (but not out of the way yet), and python/perl, pleaseeeee... we
>> don't
>> > > need any more integration/training phase.. + we need people to work,
>> not
>> > > stop bein motivated. Don't know about you python geeks, but in my
>> case,
>> > > I'm narrow minded and I don't want to know what python is :P (looks
>> > > crappy to me)
>> > >
>> > > KKRT
>> > >
>> > > On Thu, 01 Jun 2006 15:34:41 -0400, Bruno Costa < [EMAIL PROTECTED]>
>> wrote:
>> > > > I'm not an amsn developer (please, don't kill me), but if you guys
>> are
>> > > > going
>> > > > to develop a MSN backend for telepathy I'm willing to implement a
>> > > > java/swing
>> > > > frontend! (and no, java isn't slow as hell, and yes, mercury is a
>> > > > bugged piece of crap) :D
>> > > > Apart from java I prefer python (maybe with pygtk)...
>> > > >
>> > > > By the way, is telepathy suported on windows?
>> > > >
>> > > > On 6/1/06, NoWhereMan <[EMAIL PROTECTED]> wrote:
>> > > >> ----- Original Message -----
>> > > >> From: "Youness Alaoui" <[EMAIL PROTECTED]>
>> > > >>
>> > > >> > python, NO, perl, NO... I know these languages are popular,
>> but I
>> > > >> > just hate the syntax, and especially python, I heard so much
>> about
>> > > >> > it, but
>> > > >>
>> > > >> I
>> > > >>
>> > > >> > never even felt the need to look at what the code looks like, I
>> just
>> > > >>
>> > > >> hate
>> > > >>
>> > > >> > it from the start...
>> > > >
>> > > > Neither I like it so much, but maybe you have to think about it
>> from
>> > > >
>> > > >> the point of view of ease of use, more than beauty itself (even
>> if
>> I
>> > > >> agree
>> > > >> a
>> > > >> little with you :)).
>> > > >> really, it doesn't look that bad ;)
>> > > >> And btw, you said you didn't like tcl as well :D
>> > > >>
>> > > >> > moreover, the main reason why we'd avoid python (if everyone
>> agrees
>> > > >>
>> > > >> with
>> > > >>
>> > > >> > me), is that we're tcl/tk programmers here.. learning a new
>> > > >> > language,
>> > > >>
>> > > >> no
>> > > >>
>> > > >> > thanks... C code is for those who knows C code, and there are a
>> few
>> > > >> > in here, and it's still the standard programming language...
>> > > >> > if we could get the hell out of tcl/Tk (or any interpreted
>> > > >> > language),
>> > > >>
>> > > >> I
>> > > >>
>> > > >> > would 100% do it, the only problem with C code is that it's
>> hard
>> to
>> > > >>
>> > > >> create
>> > > >>
>> > > >> > GUIs with it (I think, anyways, I'm still under the trauma of
>> my
>> Qt
>> > > >> > course...), while in Tk, it's as easy as stealing a cnady from
>> a
>> kid
>> > > >>
>> > > >> (who
>> > > >>
>> > > >> > ever invented this quote???), which is why we want to stick to
>> Tk
>> > > >> > for
>> > > >>
>> > > >> our
>> > > >>
>> > > >> > GUI.
>> > > >>
>> > > >> As I said, gtk doesn't look that bad in every programming
>> language
>> > > >> (gtk is
>> > > >> C). pygtk is just a wrapper
>> > > >>
>> > > >> > What you have said though made me realize that we might be
>> going
>> the
>> > > >>
>> > > >> wrong
>> > > >>
>> > > >> > way in some stuff...
>> > > >> > we could drop the whole interpreter thing, the Data/ structures
>> > > >> > could
>> > > >>
>> > > >> be
>> > > >>
>> > > >> > held in C structure (don't talk about C++ because of ABI, but
>> C++
>> is
>> > > >>
>> > > >> the
>> > > >>
>> > > >> > nicest way to do it, I know!), and we could have a nice API to
>> > > >> > access those...
>> > > >> > and the GUI.. we could still use Tk inside C code with the Tk
>> > > >>
>> > > >> library...
>> > > >>
>> > > >> > no ?
>> > > >>
>> > > >> shoot me: I don't like how tk looks :D
>> > > >> you have to compile yourself tcl/tk 8.5 just to have antialiased
>> > > >> fonts...
>> > > >> d'uh!
>> > > >>
>> > > >> > should we drop the .tcl files completly ?
>> > > >>
>> > > >> not to be repetitive (maybe you know it):
>> > > >> http://tcl-gtk.sourceforge.net/:D
>> > > >> ok, beat me :P
>> > > >>
>> > > >>
>> > > >>
>> > > >> _______________________________________________
>> > > >> Amsn-devel mailing list
>> > > >> Amsn-devel@lists.sourceforge.net
>> > > >> https://lists.sourceforge.net/lists/listinfo/amsn-devel
>> >
>> > _______________________________________________
>> > Amsn-devel mailing list
>> > Amsn-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/amsn-devel
>>
>>
>> _______________________________________________
>> Amsn-devel mailing list
>> Amsn-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/amsn-devel
>>
>
>
>
--
KaKaRoTo
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel
--
Bruno Costa
:wq
_______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
