It’s time for your first PR


If you’ve never issued a PR, now, it’s the best time to do it for the first time.


If you think that issuing a PR is not for you, please read the following Whys and issue your PR then 🙂


The weakest argument goes first. How cool is to say that I’m the contributor to XYZ. Open Source Software has a strong position in developers’ minds so if you’d like to impress someone for any reason, this can be the way.

Fear of being ridiculed

When you issue a PR, it is reviewed. You may consider sending a PR to do not get ridiculed (in Linus style). The thing is, that laughing at your contributors doesn’t pay off. From a maintainer perspective, if people drop off, you have more work to do, as no one is willing to handle registered issues or make meaningful changes on your own. Maintaining a good relationship with contributors is a thing that works the best.

Learn from the best

Sometimes you’d like to ask a famous developer about a possible improvement to their product or just verify some technical thought. How about being given their full attention and learning some of their expertise? PR is a great way to get both at the same time. Just write your idea in the code instead of a vague human language and share it as a proposal. You’ll get it reviewed it for free and your code for sure will be a beginning of a meaningful discussion.


If none of the above work for you, think about your CV and the fact that asking for OSS contribution references is getting more popular this days. Your changes to publicly accessible projects are the best way of showing your potential.

If you’ve never issued a PR, it’s the best time to do it for the first time. Just book an evening or two and make the positive impact on the OSS environment.

Wire improvements


This post sums up my recent involvement in the Wire serializer being built by the Akka.NET team. It was an interesting OSS experience. I’m glad that I could improve the performance of this serializer .

Box me not

The initial design of constructing a serializer of a complex object was based on emitting a pair of delegates (serialize, deserialize). Let’s consider deserialization:

  1. Create object
  2. For each field:
    1. Use the following method of a ValueSerializer:

      public abstract object ReadValue(
         Stream stream, DeserializerSession session)
    2. Cast to the field type or ubox if the field is a value type
    3. Load the deserialized object and set the field.

The problem with this approach was manifesting for classes with many primitive properties/fields the cost of boxing/unboxing might be quite high. On the other hand, one couldn’t be calling a method returning a common type without boxing for value types. How would you approach this? My answer was to move emitting point 1 & 2 to the value serializer and provide a generic implementation for this emitting in the basic class. That allowed me to customize the emitting for primitive value types like int, long, Guid still preserving a possibly bit less performing generic approach.

After the change and delegating the emitting to the ValueSerializer class, it was given two new virtual methods with their implementation using boxing etc, but leaving much more space for special cases

public virtual int EmitReadValue(Compiler<ObjectReader> c, 
   int stream, int session, FieldInfo field) 
public virtual void EmitWriteValue(Compiler<ObjectWriter> c, 
   int stream, int fieldValue, int session) 

Call me once

Wire uses a BCL’s Stream abstraction to work with a stream of bytes. When using a stream, a conversion to primitive value types sometimes require a helper byte array to get all the data in one Read call. For instance, a long value is stored as 8 bytes, hence it requires an 8 byte array. To remove allocations, during serialization and deserialization, a byte chunk can be obtained by calling GetBuffer method on the session object. What if your object contains 4 longs. Should every serializer call this method or maybe it should be called once and the result stored in a variable?

I took the second approach and by removing this additional calls to GetBuffer was able to squeeze again a bit more from Wire.

Summing up

Working on these features was a very pleasant experience. It took me just a few evenings and I was able to make a positive impact. And this is really nice.