8 ms·

No, if you think there are problems with cgo, the solution is to address those problems, not reinvent it. If you have performance concerns, file a bug or commen

by uluyol 9y ago

No, if you think there are problems with cgo, the solution is to address those problems, not reinvent it. If you have performance concerns, file a bug or comment on an existing one. Also, I don't see any reason why jni should be slower than cgo. Go has its own scheduler that brings overhead to cgo and needs to switch stacks whereas Java doesn't have to deal with such things.

kbenson 9y ago
> No, if you think there are problems with cgo, the solution is to address those problems, not reinvent it. If you have performance concerns, file a bug or comment on an existing one. Well, sometimes the solution is to reinvent it and provide another solution. Sometimes a project has a specific goal which might preclude them from using your idea, or the people involved just have a slightly different vision. Sometimes, if you believe the existing project is wrong from the ground up, the solution is to reinvent it as something else. Sometimes it doesn't pan out, sometimes it does. That's the beauty of open source.
valarauca1 9y ago
>If you have performance concerns, file a bug or comment on an existing one. Excuse my language, or don't. But the Go-Maintainers really don't give shit about improving their languages performance. Also FFI ALSR is disabled for debugging simplicity. Which I can only imagine means they debug by reading literal core dumps by hand. Furthermore I'd rather not donate my time and energy to a company as large as Google. >Also, I don't see any reason why jni should be slower than cneeds to switch stacks whereas Java doesn't have to deal with such things. The JVM has its own scheduler to keep locks fair, also OpenJDK does green threading in its runtime to allow for GC cycles on JIT'd code. I'm pretty sure Oracle and Azule do a well since JIT execution/cleanup requires doing stack swapping.

by uluyol 9y ago

kbenson 9y ago

> No, if you think there are problems with cgo, the solution is to address those problems, not reinvent it. If you have performance concerns, file a bug or comment on an existing one. Well, sometimes the solution is to reinvent it and provide another solution. Sometimes a project has a specific goal which might preclude them from using your idea, or the people involved just have a slightly different vision. Sometimes, if you believe the existing project is wrong from the ground up, the solution is to reinvent it as something else. Sometimes it doesn't pan out, sometimes it does. That's the beauty of open source.

valarauca1 9y ago

>If you have performance concerns, file a bug or comment on an existing one. Excuse my language, or don't. But the Go-Maintainers really don't give shit about improving their languages performance. Also FFI ALSR is disabled for debugging simplicity. Which I can only imagine means they debug by reading literal core dumps by hand. Furthermore I'd rather not donate my time and energy to a company as large as Google. >Also, I don't see any reason why jni should be slower than cneeds to switch stacks whereas Java doesn't have to deal with such things. The JVM has its own scheduler to keep locks fair, also OpenJDK does green threading in its runtime to allow for GC cycles on JIT'd code. I'm pretty sure Oracle and Azule do a well since JIT execution/cleanup requires doing stack swapping.