On 9/20/05, Mike Hansen <[EMAIL PROTECTED]> wrote: > This is an opinion from someone who has worked extensively in both Java and > C++....if the application requires high performance(say auto routing, hint, > hint) Java will be a factor of 3-5X slower than C++. And it will be a > memory pig, on most JVMs the "Hello World" app will consume 10MB+ just on > it's own. An app the size of PCB will likely consume 60-100MB. And when > the garbage collection kicks in at seemingly random times...look out.
Do not judge garbage-collected languages on Sun's JVM. Do not even judge all Java implementations against Sun's JVM. Sun is very well aware that there are alternative allocation strategies and GCs that are **MUCH** faster and more efficient than the one they're using. Ask most any Lisp based system. Also, GC-based languages WILL tend to use more memory than their C-derived equivalents, because of the garbage collection. However, incremental and/or concurrent GCs tend to reduce the amount of garbage "in real-time" better than more traditional methods. And speaking of Lisp, why are we talking about this at all? gschem itself is already written with large amounts of Scheme, if I'm understanding things right. Scheme is a relatively portable language implementation. It has a rock-solid garbage collector. It's easily "fast enough" for what we're trying to use it for except maybe for auto-routing. It trivially interfaces to C. Am I missing something here? Why not use Scheme? This would also let people re-use the UI elements of gschem in other applications too, allowing them the ability to appear more integrated, even though they're really implemented as a bunch of small cooperating tools. It's a win, win, win scenario. > Suggest finding a cross platform toolkit. Also suggest finding something so > that it can easily be compiled/installed on Windows. The only reason I keep > a Linux box around here is to run gSchem and PCB. I know, I've installed > PCB on my Windows box here with Cygwin,X11, etc. But most users don't or > can't go to those type of pains. It's a bit too late now, but you could perhaps have run Linux inside the qemu virtual machine emulator. I know it runs Linux well. It may not be as fast, but as long as the code doesn't execute too many system calls (its emulation of user/kernel space transitions is a bit slow), it offers, to me at least, quite acceptable performance. Anyway, this is a bit OT. I'll cease this thread now. :) -- Samuel A. Falvo II
