Library Performance vs. Stupid Mistake Friendly

[sothatsit]

Hey,

I am making a simple wrapper for LWJGL that wraps some of the functionality to make it easier to use. Basically to make it into more of your traditional and preferred object-oriented format instead of many static function calls and un-conventional data types (Like ByteBuffer instead of byte[]).

Now the dilemma i am facing is how much should i move to correct people’s errors in using the library, the tossup being performance vs debugging ease.

For example, many of the GLFW window handling methods should only be ran on the main thread. I could check if the current thread is the main thread, but this is a little bit of an expensive call, not hugely, but a little bit.

I don’t want to go too bare bones, then people might as well just be using LWJGL directly, but i still want it to perform very well.

Just was wondering what other people thought was a good sweet spot between performance and convenience.

[BurntPizza]

For your specific example, caching and passing the current thread id through underlying calls would all but remove the overhead.

[sothatsit]

@BurntPizza

For your specific example, caching and passing the current thread id through underlying calls would all but remove the overhead.

Requiring the user to pass the current thread whenever they want to set the size of the window seems a little messy.

[nsigma]

@sothatsit

@BurntPizza

For your specific example, caching and passing the current thread id through underlying calls would all but remove the overhead.

Requiring the user to pass the current thread whenever they want to set the size of the window seems a little messy.

Yuck!

This doesn’t seem the sort of thing that should be polluting your API. What about using assertions instead? These sort of checks sound like the sort of thing that should be switched off in “production” code anyway.

[gouessej]

Hi

Hiding the NIO buffer is a bad idea especially with the library that you’d like to wrap, it requires direct NIO buffers for numerous calls, they aren’t backed by a Java array by default, you would double the memory footprint with that.

I agree with nsigma’s suggestion, it’s a good compromise, it doesn’t force the developer to pass the thread.

[sothatsit]

@nsigma

@sothatsit

@BurntPizza

For your specific example, caching and passing the current thread id through underlying calls would all but remove the overhead.

Requiring the user to pass the current thread whenever they want to set the size of the window seems a little messy.

Yuck!

This doesn’t seem the sort of thing that should be polluting your API. What about using assertions instead? These sort of checks sound like the sort of thing that should be switched off in “production” code anyway.

I already use assertions through my code to verify if the values they enter are valid and not null. I am not sure if there is a better way to do it, but currently i just do something like

Assert.nonNull(value, message);

which throws a NullPointerException if the value is null and

Assert.isTrue(value, message)

which throws an IllegalArgumentException if the value is false.

@gouessej

Hi

Hiding the NIO buffer is a bad idea especially with the library that you’d like to wrap, it requires direct NIO buffers for numerous calls, they aren’t backed by a Java array by default, you would double the memory footprint with that.

I agree with nsigma’s suggestion, it’s a good compromise, it doesn’t force the developer to pass the thread.

I have not delved into the OpenGL part of the library, but the other parts such as GLFW require quite small buffers, the largest being the GammaRamp. Most of the buffers used are for structs, which are not friendly to use, so i convert them into another object which is easier to use. The other times buffers are used are when they need more than one variable to be returned, such as count or width and height.

Although i have not looked into OpenGL much, i imagine it is the part which uses a huge amount of buffers for sending vertex, color or image information to the graphics cards. I do not plan on removing that use of buffers as they make sense for the situation.

[nsigma]

You need to learn what Java assertions are!

http://docs.oracle.com/javase/7/docs/technotes/guides/language/assert.html