How much optimized is Vala generated C code over hand written C code?

Question 1

As a Vala developer I wouldn't suggest Vala for an interpreter. In an interpreter you're going to create many objects for ast, data types, possible intermediate objects, codegen objects and so on. In Vala itself I've personally measured that the major overhead is creating objects (that are simple GTypeInstance, not even GObject). Vala is designed to work with gobjects, but gobjects aren't designed to be allocated fast.

So, for your project I'd still be using glib/gio for cross-platform stuff, like networking, string utils, unicode, data structures and so on, because they have a clean, consistent and convenient API, but I wouldn't create ast objects as gobjects/gtypeinstance. In an interpreter you want fast allocation, that's the whole point.

My personal advice is: use vala if you want to build desktop applications, dbus services, gstreamer stuff or anything that touches the g* world, nothing else.

Question 2

It depends on what you would have done writing C. In particular:

Since I can write GObject based C code by hand, what is your threshold? Handwritten GObject-based C versus Vala-written GObject-based C? Probably comparable since Vala is going to generate more or less the same library calls as a human would.
GObject classes are technically optional. You can mark a class as [Compact] to skip all the GLib code generation for a class, which will be much faster, although you will lose many of the features, such as virtual methods, if you do so. This will still have slightly more overhead than an object written in C, but it comes with thread-safe reference counting and a few other things that a typical C programmer wouldn't bother doing.
Vala generates a lot of temporary variables. If your C compiler has optimisation at all, most of these temporaries will be eliminated. The bulk of Vala's control structures match with their C counter parts so a Vala if will not be shockingly more expensive than the C if.
Vala tracks references to do memory management at compilation time. Normally, this is cheap, but it can cause extra duplication of arrays and strings. Particularly, if you copy an unowned string to an owned variable, strdup will be automatically called. This means generated Vala will create more of these small, temporary objects, but, if it really is a problem, you can judiciously use unowned to limit their creation.

Question 3

The vala compiler generated code uses GObject library. In case it is needed to avoid GObject, I suggest using the aroop compiler which uses vala parser to parse vala code but does not use GObject in the generated code.

Aroop compiler generates code that uses object pool which is optimized for object creation and manipulation. The collection of objects has data oriented features. For example the objects can be flagged and the flag can be selected while traversing the objects in a very efficient way and the objects are all in close distance in perspective of memory location.

The aroop compiler is used to write shotodol project which does not have a GUI of it's own. It has module and plugin system. It has a command line interface that enables people to write server application. An example of server application using shotodol exists here as shotodol_web. I wish people who like this project share their issues in the project page.

Question 4

A generated code is never as optimized as a well designed hand written code, because the optimizer can not know the design goal. However, an optimizer creates optimized code more consistently then a human programmer would do. Also you should define your goals and then check if the performance requirements are met by the selected tools, not the other way around. Optimizing is not a design goal, it's a task that may need to be adressed, so first define your requirements and then think about how to reach it.

Premature optimization is the root of all evil. :)