Few days ago I tested Eclipse C++ (see here) and was actually pleased with the results. Today in office I needed to work with a C++ pipeline tool and decided to convert it to Eclipse C++ while I was working on it.

Overall it went really smoothly and I like Eclipse C++ more and more. Here are the few things I needed to do.

1. To edit your project building properties, go into the “Project Explorer” panel on the left, right click your project and select “properties”. Then unfold “C/C++ Build” and select “Settings”. The good thing is you can edit both debug and release configurations to set identical settings, so in the “Configuration” drop down select “[ All Configurations ]”
2. There is no #pragma comment(lib,”mylib.lib”) to link with libraries. So make sure you go to “MinGW C++ Linker” then “Libraries”. Add the name of the library without .a nor .lib in “Libraries”, and add the path in “Library search path”. The specific project I worked on used DevIL the image library and the linker had no problem linking with the provided libraries. Again the trick is to remove any suffix from the library name. If you enter Devil.lib into the settings, the linker will complain about not being able to find the library. Change that to Devil (without .lib) and the linker will find it.
3. If you compile your project with default settings you will most likely need to ship it with libraries like libgcc_s_dw2-1.dll or libstdc++-6.dll, so again in the settings page, go to “MinGW C++ Linker” then “Miscellaneous” and in the linker flag box add -static. This will increase a bit your executable size but will make it easier to deploy and overall will be smaller than shipping with all the Dlls needed.

Overall I already made two small projects with Eclipse CDT this week and it went as smoothly as it should, and as smoothly as VS, so the next test will be a project with more Windows / DirectX specific code. But so far, Eclipse CDT seems like a perfectly viable free alternative to VS.

Javascript is surprisingly fast in modern browsers, but as for every language you will need to optimize at some point. I found a very useful website called JSPerf which provides a test framework, allows you to create and edit existing test framework, provides online persistence allowing to get wider results than if you ran them by yourself.

A simple example. I was wondering what was the fastest way to convert from a float to an int in Javascript. I had several options, and the best way was not as suggested by some colleagues. And the way to make sure what is the fastest way is to benchmark, and not to guess. The results of the benchmark are here, you can test on your machine by running the test. Your results will be stored and shared with everyone, enhancing the global knowledge. The fastest I found is the following, if you find faster, please let me know.

myInt = myFloat | 0

A second example. What is the fastest typed array to write and read integers? The results are here and sadly there is no fastest answer for all browsers. So if you do not want to complicate your code with browser tests and everything that goes with it, the best solution is to use the following.

var myArray = new Int32Array( size );

A third interesting example about the fastest way to clear a buffer and copy it in a canvas every frame. The results are here. The fastest way is to create a working buffer outside your frame, create another one initialized with the values you want, and copy using the method set every frame.

At initialization time

var external_data_1024 = ctx.createImageData(1024, 1024);
var external_source_1024 = ctx.createImageData(1024, 1024);

During the frame processing

external_data_1024.data.set(external_source_1024.data);
ctx.putImageData(external_data_1024, 0, 0);

Finally a word of caution, make sure you benchmark the right things.

1. The initial float to int did not include the two solutions I added to the benchmark |0 and >>0, so having something that look fast does not mean you have found the optimal solutions.
2. The original array speed test included array creation for the write, so the test was measuring creation+write instead of just write, and the results were very different. So make sure to measure what really matters to you.
3. The last example was a subtle example of the points #1 and #2 above. The initial “fastest” function included unnecessary code in clear_canvas(), adding a new test without that code proved to be faster. The loop test was looping with a double indirection “data.data[i] = 0;”, removing that indirection made it much faster and measured the real filling time instead of the sum of filling time+overhead with “buffer[i] = 0;”.