"Walter" <newshound@digitalmars.com> wrote in message news:d9j3i1$qp8$2@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d9ius8$inm$1@digitaldaemon.com...
>> "JNI overhead"? JNI stands for "Java Native Interface",  what is wrong with it? Just wondering...
>
> It's been many years since I looked at it, but as I recall Java cannot
> call
> C code directly. It has to run through a JNI interface which does things
> like reorder the parameters on the stack to match the C calling
> conventions.
> There are also issues with transferring object references due to the GC.
>
>

Reordering parameters....
It depends on direction of stack growing in particular JavaVM
implementation.
Main problem that you need to pass additional parameter like
JNIEnv.

But in my particular case: I am not using standard JNI - all native
functions
have the same signature: void func(JSVM* vm, void* params, void* result  ).
params and result are pointing directly into Java stack area.
Each native function is casting params to some structure describing java
parameters, so no need to reorder - direct mapping.

In any case if you are treating Java as a 'glue' language/environment
for native components then even standard JNI is acceptable - do
in bytecode what is better to do in bytecode and in native what
is naturaly native and this is it.

"issues with transferring object references due to the GC" - it is problem in multithreading GC, afaik.

Andrew.

"Walter" <newshound@digitalmars.com> wrote in message news:d9j452$s1b$1@digitaldaemon.com...
>
> "Mike Parker" <aldacron71@yahoo.com> wrote in message news:d9i0hu$k8s$1@digitaldaemon.com...
>> These days, I'm more inclined to disbelieve someone who says 'such-and-such is slow', even if they back it up. Too many times I have seen people back up their arguments with meaningless microbenchmarks (often improperly measured), ouutdated experiences, or experiences with apps that were poorly written in the first place. I often get the same FUD when I talk to people about D ('yuck, GC! What a performance killer' - this from a guy who spent a few weeks testing and debugging his own custom memory manager in C++). The real test comes from personal experience. No matter what garbage I hear or read on the net, I know Java is performant because I've used it extensively. I know GC doesn't kill my apps because I've been working with GC'ed languages for a few years now. I know that neither D's lack of a good debugger nor it's lack of an STL equivalent hinder my development. Those who say otherwise can rant on and leave me be.
>
> I was on the "explicit memory allocation is obviously faster than gc"
> train
> for many years. Until I started working with gc's. Then I discovered to my
> amazement that gc'd apps can actually be faster. The reasons are:
>
> 1) the code doesn't have to keep track of who owns the memory. Reference counting, for example, can be surprisingly costly.

It is the same as "GC can be surprisingly costly."
Can be and can be not.

As an "educated GCier" I would like to have a choice.

Again true is in the middle - in the balance of many approaches.
Support of stack intializations (struct ctor/dtor or class stack
allocations)
is also here, BTW.

>
> 2) often, the "keep track of who owns the memory" is done by "when in
> doubt,
> make extra copies of the data". This of course means "slow". I've found
> that
> gc'd apps tend to make a lot fewer allocations, and nothing speeds up
> overall memory allocation more than doing fewer allocations.
> 3) C's (and C++'s) idea that strings are null-terminated means slicing
> doesn't work, and lots of extra copies are made.

"lots of extra copies are made."

Surprisingly but in real life D slicing does not change anything here dramatically.

See:

class URL
{
     char[] src;
     char[] domain() {  return src[x..y].dup;  }
}

const slicing is better and allows to reduce many cases of needless allocations:

class URL
{
     char[] src;
     const char[] domain() {  return src[x..y];  }
}

'const' is not ideal - it is just one more convenient tool for particular domain.

>
> Of course, it's possible to work around these problems in C++, and I've
> seen
> it done, but it requires complicated custom code, and very few ever
> bother.
>

Oh, yeh, any effective system requires "complicated custom code". "complicated custom code" will be always there. GC/heap does not really matter - nor GC nor heap are silver bullets.

E.g. in Harmonia I am allocation HTML DOM elements manually for many reasons.

Andrew.

I'm just going to bump this thread.  Just in case someone who has had terrible GC performance has missed this topic & is sobbing in a corner somewhere.

Brad

I think I would, indeed, be worried if anyone encountered problems *that* severe.

-[Unknown]


> I'm just going to bump this thread.  Just in case someone who has had terrible GC performance has missed this topic & is sobbing in a corner somewhere.
> 
> Brad