gupnp-media-server now written in Vala

I finally managed to port all the existing C code to Vala. What did i achieve from this exercise? For one thing, the code got much simpler, with LOCs being reduced from 2101 to 1117 (46.8 %). Also this proves that (at least the server-side) GUPnP's Vala bindings are already in a stable/usable state.

Special thanks to Jürg Billeter, Ali Sabil and Jussi Kukkonen for their continuous support during this exercise and for quickly fixing bugs that I reported.

Comments

Unknown said…
What about the performance? comparing before and after? any gain? any loss?
June 16, 2008 at 12:40 AM
zeenix said…
What about the performance?

The memory usage remains around 500-600KiB and regarding the performance, I didn't notice any difference at all. My control-point UI is still able to quickly get the results, admitted that I didn't do any systematic comparison/profiling but I seriously doubt there should be any significant overhead introduced by Vala.
June 16, 2008 at 1:54 AM
Unknown said…
That should be advertised more, if true, that porting C apps to vala doesn't bring performance down, compared to porting to python or java or mono.

In order that nobody gets me wrong I do most of my code in python or mono.

But if vala can give ease of code with C like performance, the world has to know. And you have a good study case here.
June 16, 2008 at 5:26 AM
Anonymous said…
Quoting from the FAQ:

How does the performance of Vala applications compare to other applications?

The performance should be pretty similar to GObject/C-based code as there is no Vala-specific runtime library/environment that needs to be loaded. The C compiler can also apply the same optimizations on Vala-generated C code and plain GObject/C code. The Vala compiler uses reference counting in more places than most GObject/C-based applications do. However, Vala allows to fine-tune that easily in performance-critical sections with the weak modifier.
June 16, 2008 at 5:33 AM
zeenix said…
Here are some actual numbers on performance and memory usage.
June 16, 2008 at 5:39 AM
Unknown said…
The interesting thing with your app is that it's a fully functionnal app being ported from full C to full vala, it's not a "useless" benchmark tool, it's a real app, with real use.

I think it's the first I ever seen being ported like that so I thought it might be interesting to compare, and so, comfort what is assumed in the FAQ of vala.
June 16, 2008 at 7:31 AM
Post a Comment

Popular posts from this blog

Welcome to the virtual world!

Image
About two months ago I informed  the followers of this blog that I will now be working on SPICE project  for Red Hat . Judging from the questions I was asked after that, I realized that not many people know about SPICE so I thought I write at least one blog entry dedicated to explaining what SPICE is all about. Before I get to SPICE itself, let me first introduce you to the world SPICE lives in. Virtualization and Virtual Machines (VMs) For some reason, I feel that I should leave the definitions to wikipedia  and only quote it so that is what I am going to do: " Virtualization, in computing, is the creation of a virtual (rather than actual) version of something, such as a hardware platform, operating system, a storage device or network resources. " " A virtual machine (VM) is a "completely isolated operating system installation within your normal operating system".Today, this is implemented by either software emulation or hardware virtualization ". V
Read more

clutter-gst

After I was informed about the existence of ClutterGstVideoSink, I quickly modified my super-video application to make it use that. But as soon as i did that, i stopped getting even the static image. After careful analysis for days, I figured that I was supposed to call gst_bus_add_signal_watch() on the pipeline bus since ClutterGstVideoSink uses messages on the bus combined with signal handlers to render the frames in the application thread. This is obviously a 'dirty' hack; a hack because gst elements are supposed to do all the media processing in the pipeline thread, dirty because gst bus is not meant for media transport. After this realization, I had been working on it from time to time. First I tried to make the actual rendering happen in the gst pipeline thread by using the clutter's thread safety primitives and that worked quite nicely in the end except for one minor problem: The call to clutters rendering thread blocks if it happens after the clutter main loop has b
Read more

Shame Ubuntu shame

I am no more a fan of Ubuntu. The reason is their recent demonstration of lack of community spirit. Here is the release announcement of Ubuntu hardy alpha6. If you scroll-down you can see the gnome-system-monitor's new cool "Resources" view featured with a nice screenshot. Since Karl-Lattimer worked really hard to make this happen, he asked to be given personal credit on that page. Don't know about others but I see this as a very reasonable thing to ask. The result of this request can be seen in the announcement of hardy beta. They just removed the feature from the announcement. Shame Ubuntu shame. UPDATE: It's interesting how most of the comments that are from people who got pissed without actually caring to understand the main point of this blog entry (which me and Karl-Lattimer tried to emphasize in the comments) are posting as Anonymous. :) Acknowledging the possibility that they might not think comments are worth reading before commenting, let me make it c
Read more