Each Benchmark Execution will store the result of a Benchmark Definition executed while the project was checked out at a given commit on a certain machine. Executions: A Benchmark Execution is the combination of Benchmark Definitions, commits, and machines.A list of allowed machines to run this benchmark on.A list of commands that will give the result of the benchmark.Definitions: A Benchmark Definition is a set of properties.
#Imvu products biz software our screenie code
Projects: A project represents a git repository with the code we want to benchmark or the project we want to use to benchmark other projects.Layouts: A Layout is a group of projects that work together for benchmarking purposes, and this tab will show us the list of Layouts configured in BlueSteel.git checkout -b wip-render-slot-split git push -u origin wip-render-slot-splitĪfterwards, we went to the BlueSteel main page, which allows us to manage the different concepts listed below: At this point, BlueSteel took few minutes to notice the change and feed all the information to its database. After that, the commits were pushed to our Github repository. With git, we created a branch to start the experiment, and we committed some code. This was an experiment in preparation for rendering transparent elements using the Depth Peeling technique. This gives us the ability to quickly react to a performance degradation, and more importantly, the author of the commit, who has the most context on that code, will be notified very quickly, before that context is lost. In addition, it gives us the ability to freely experiment with new ideas on non stable branches and see whether the resulting code performs better or worse compared to the stable one.Īs an example, we are going to expose a real situation of how BlueSteel detected a performance issue, and how BlueSteel helped us by notifying us to fix it. We started from the idea of splitting the list of elements to render between opaque and transparent ones. In the case this output follows an specific schema, BlueSteel will understand the data and will inform the commit author if a fluctuation exists between Benchmark Executions. The ability to check every commit on any branch in our projects is very important. Given a set of commands that we will call “ Benchmark Definition”, BlueSteel will execute them and will read and store its output on something called “ Benchmark Execution”. I spent several late evenings and even some weekends to build what we now call BlueSteel.īlueSteel is a tool to help track the performance of our projects by commit, branch, and machine. We suffer from this problem enough that I found it worthwhile to look into in more detail. We hacked a rough solution trying to minimize the performance regressions we had in our 3D engine, and the solution quickly paid off, informing us which were the commits affecting the performance of our 3D engine. While it wasn’t part of the original IMVU schedule, we encourage engineers to solve problems they see, and I took it upon myself to create a tool that solved this problem.
For example, unit testing combined with Valgrind has helped us track down a lot of memory leak problems.Ī single code commit can subtly affect the speed and performance of the 3D engine in ways that are not obvious to the engineer.
These may range from simple problems of code that will not compile, to harder problems like memory leaks. At IMVU, we have automated solutions in place to help find these kinds of problems. While writing the source code of a 3D engine, we can have many types of problems.
0 kommentar(er)
