Add nanobench, a fresh look at our microbenchmark harness.

gyp/bench.gyp

 # GYP file to build performance testbench.
 #
 {
   'includes': [
     'apptype_console.gypi',
   ],
   'targets': [
     {
       'target_name': 'bench',
       'type': 'executable',
       'dependencies': [
-        'etc1.gyp:libetc1',
         'flags.gyp:flags',
         'jsoncpp.gyp:jsoncpp',
         'skia_lib.gyp:skia_lib',

[djsollen, 2014/06/25 19:52:40]

if skia_lib is pulled in by the bench gypi then we can remove it from here as
well.

[mtklein, 2014/06/25 20:28:08]

Let me hold off on this for another CL.  I actually would prefer to reorganize
our GYPs pretty much the other way, so that each of these binaries could build
as an empty but functioning shell app if you commented out the includes.  It'd
be nice if the tool specified the tool's deps and the include brought in the
include's deps.

         'tools.gyp:crash_handler',
-        'tools.gyp:resources',
-        'tools.gyp:sk_tool_utils',
         'tools.gyp:timer',
       ],
       'sources': [
         '../bench/BenchLogger.cpp',
         '../bench/BenchLogger.h',
         '../bench/GMBench.cpp',
         '../bench/GMBench.h',
         '../bench/ResultsWriter.cpp',
         '../bench/benchmain.cpp',
       ],
       'conditions': [
-        ['skia_gpu == 1',
-          {
-            'include_dirs' : [
-              '../src/gpu',
-            ],
-            'dependencies': [
-              'gputest.gyp:skgputest',
-            ],
-          },
-        ],
-        ['skia_android_framework == 1',
-          {
-            'libraries': [
-              '-lskia',
-            ],
-          },
-        ],
+        ['skia_android_framework == 1', {
+          'libraries': [ '-lskia' ],
+        }],
       ],
       'includes': [
         'bench.gypi',
         'gmslides.gypi',
       ],
     },
+    {
+      'target_name': 'nanobench',
+      'type': 'executable',
+      'sources': [
+        '../bench/nanobench.cpp',

[tfarina, 2014/06/25 20:06:25]

NanoBenchMain.cpp?

otherwise can it be either nanobench_main.cpp or nanobenchmain.cpp

[mtklein, 2014/06/25 20:28:08]

I prefer nanobench.cpp.  It compiles into a binary named nanobench.  There's no
Nanobench class to collide with.  Why complicate things?

[tfarina, 2014/06/25 21:08:04]

I don't understand why you call naming a file nanobench_main.cpp or
nanobenchmain.cpp, complicate anything. If you come later and add a class
NanoBench then that will complicate things. That is what already happens with
dump_record.

+      ],
+      'includes': [ 'bench.gypi' ],
+      'dependencies': [
+        'flags.gyp:flags',
+        'tools.gyp:crash_handler',
+        'tools.gyp:timer',
+      ],
+    },
   ],
 }