No he said see what the bottleneck is.

Basically you always want the GPU to be drawing something. While it is drawing it can still receive commands into its queue. So you want to be sending commands while the GPU is always working. If you send 1 command to draw 1 triangle and then send a another command after that, the gpu will draw that triangle so fast that it will be waiting for your second command. So imagine it takes 1/20th of a second to send a command glVertex3f() to the GPU. And your gfx card can draw 1 million tri's per second. Thats 50K triangles you can draw in the time it takes to send a command to the GPU. So these numbers are just examples, but you can see that the time it takes in this example:

-Drawing 1 vertex at a time, you are wasting all this time communicating to the GPU, and it is finishing your draws almost immediately. So it is waiting for work to do (another 1/20th of a second just to receive a work order).
-Drawing 50K in 1 batch, you talk to the GPU one time, and doesnt need to wait for you to tell it what to do next, it can just loop through those verts and be done with them by the time it receives your second command which will take 1/20th of a second from the time it received the first command.

So if your CPU is sending commands but your GPU is not finishing the commands, but forcing to queue them up (a back log of commands), then you are GPU bound because your GPU can't finish work orders as fast as the CPU wants. So if you have a backlog of 10000 commands and you reduce your glXXXXX() calls to 100, it still might have a back log of 100 commands. Meaning still, the GPU can only work on 1, and has 99 other work orders it received.

okay... then the benefit of batching is only reducing calls on the CPU side? there is no benefit on the GPU side?

Yes, with opengl this is normally the case as the implementation (the opengl32.dll that comes with your graphics driver) is allowed to create(or split) batches on its own before shipping them off to the GPU, This means that with OpenGL you can make 500 draw calls and still only get one context switch and one batch of data sent to the GPU if the implementation is clever enough (This is not the case with D3D9 though).

Thus batching of vertex data doesn't reduce or simplify the work for the GPU, it lets you get more work to the GPU in less time.

As reducing the number of draw calls had a fairly small impact on performance for you it is likely that you are allready limited by the GPU.

You havn't said what your framerate is so here are a few pointers:

1) If your frame rate is stable at 60 (or whatever your monitors refresh rate is) Then you are limited by vertical synchronization (Your graphicscard is waiting for the monitor to refresh before drawing additonal frames), this can be disabled in the driver settings for testing purposes.

2) If your framerate is above 500 then you should stop optimizing and focus on the game.

3) If increasing or decreasing the resolution has a significant impact on framerate then you are most likely limited by the GPUs fillrate or pixelshader stage. (Reducing drawcalls or even vertex count will have little to no impact here, reducing overdraw can greatly boost performance though)