About the author

Miron Abramson
Me
Software Engineer,
CTO at PixeliT
and .NET addicted for long time.
Open source projects:
MbCompression - Compression library

Recent comments

Authors

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2014

Creative Commons License

Blog Flux Directory
Technology Blogs - Blog Top Sites

HttpCompression on IIS7 (Using MbCompression library)

If You have full control on the server, you probably don't need my compression library MbCompression, But if you are using share hosting, sure you do.

I just uploaded the configuration for the compression library to work on IIS7.  Check the latest source code from here

Currently rated 4.6 by 7 people

  • Currently 4.571429/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Posted by Miron on Thursday, July 23, 2009 8:46 AM
Permalink | Comments (5) | Post RSSRSS comment feed

Why I think I will stick with WebForms

The MVC concept is clear and logic and the guys at Microsoft did a very good job with the new MVC Framework , But I think I will stick with the 'old fashioned' WebForms and this is why:

1. I don't need anybody to 'force' me to seperate my code into layers. I do it any way in every site I build. I have a DataAccess layer, a Business logic layer and a 'View' layer, and I know exactly when and where to use each layer.

2. I build web sites. I don't need my code to work with any other 'View' other than HTML, and if I do, as I mentioned before, my Business logic layer is in a seperate dll so I can reuse it.

3. One of the first things I do when I start a new project is to disable the ViewState in the web.config, which leaves me with a hidden field with about 50 chars length (aroung 50bytes) - I can live with that. That will not slow down my site. If the page is not doing any POST, I can remove the <form runat="serve"> from it, and then there will be no ViewState at all.

4. I heavily use JavaScript and Ajax (usually with jQuery & my own js 'framework') to give better user experiance.

5. The only 'Databinding controls' I use are Repeater and ListView (and DropDownList) that are rendering exactly the HTML I want.

6. The only server control (other than  'Databinding controls') I use are HyperLink,Literal and PlaceHolder that not render any extra HTML other then what I want.

7. I heavily use inline expression

8. I use short 2-3 chars names for my controls.

9. I do use NUint (truly, only when I must)

10. I use httpcompression to improve performance.

11. I use Url rewriting if needed.

12. My code is well organized and very easy to maintain.

13. I know all the little secrets of the ASP.NET framework and know how to take it to it's limits

 

I bet my sites have no worse performance than MVC sites or any other technology  and I'm sure it will take me less time to build a well organized site with all the points above.

I built and designed tens of sites. From small, medium to very large, and never had a performance problem that couldn't be solved by using the above points.

Use MVC if you want to be cool. I will stay with my oldy friend - WebForm

Why should I replace a winning horse ?

Currently rated 3.5 by 21 people

  • Currently 3.523809/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:
Categories: ASP.NET | C# | Performance
Posted by Miron on Friday, February 13, 2009 6:26 AM
Permalink | Comments (21) | Post RSSRSS comment feed

Fast version of the Activator.CreateInstance method using IL

We all know (I guess) the method Activator.CreateInstance(Type) and the generic version:  Activator.CreateInstance<T>()  that are used to create an instance of a specified Type.

In now days all are talking about 'Entity-relationship model' , 'Object-relational mapping' and that stuff, that basically it means getting a IDataReader, loop over it and fill with the data a List with specfied type of objects and return a List instead of DataSet or DataTable (or similar mechanism). While looping over the IDataReader, every iterate, an instance of the specified type needs to be create. It can be done using one of the methods above, but it can be improved by usind IL and some help using some cache. Here is how can it be done:

public static class FastObjectFactory
{
    private static readonly Hashtable creatorCache = Hashtable.Synchronized(new Hashtable());
    private readonly static Type coType = typeof(CreateObject);
    public delegate object CreateObject();

    /// <summary>
    /// Create an object that will used as a 'factory' to the specified type T 
   /// <returns></returns>
    public static CreateObject CreateObjectFactory<T>() where T : class
    {
        Type t = typeof(T);
        FastObjectFactory.CreateObject c = creatorCache[t] as FastObjectFactory.CreateObject;
        if (c == null)
        {
            lock (creatorCache.SyncRoot)
            {
                c = creatorCache[t] as FastObjectFactory.CreateObject;
                if (c != null)
                {
                    return c;
                }
                DynamicMethod dynMethod = new DynamicMethod("DM$OBJ_FACTORY_" + t.Name, typeof(object), null, t);
                ILGenerator ilGen = dynMethod.GetILGenerator();

                ilGen.Emit(OpCodes.Newobj, t.GetConstructor(Type.EmptyTypes));
                ilGen.Emit(OpCodes.Ret);
                c = (CreateObject)dynMethod.CreateDelegate(coType);
                creatorCache.Add(t, c);
            }
        }
        return c;
    }
}

Note the static HashTable is been used as a cache. The first  time we create a delegate 'CreateObjec' for the given type it is 'slow', so all the point here, is to cache this delegate. The next time we need to create an object from the given type, the 'CreateObjec' delegate will be used from the cache. Without caching it, the whole story worth nothing.

Here are some benchmarks:

1 Object:



100 Objects:

1000 Objects:

Comparing to the generic constraint : new()

Below there is the small project I used for the benchmarks:

FastObjectFactory.zip (50.35 kb)

Currently rated 5.0 by 6 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Categories: C# | Performance | IL
Posted by Miron on Saturday, August 09, 2008 12:52 PM
Permalink | Comments (19) | Post RSSRSS comment feed

High performance css minifier

It is known that minifying the JavaScript and CSS files can really reduce the files size and improve the general site performance. Lot of sites (BlogEngine.NET among them)  do it on run-time and not it the build time. At this point, I want to recommend the JavaScript minifier JSMIN by Douglas Crockford. It does the job very good, and by far, much faster than all the RegularExpression \ Replace minifiers. Because in my Compression project MbCompression I do the minifying on run-time, I decided to use jsmin minifier.

The Css minifier

All the Css minifiers I found are using Regular Expression\ Replace to remove the unneeded characters. This is working fine, but have a realy bad performance, special on run-time. The speed is slow (special using the Regular Expression), and another important thing is, every Replace creates a very big string in the memory! (Strings are immutable, remember?), so if you have several Replaces, it creates several big strings in the server memory!

To improve performance, I took  JSMIN idea, that are not using any strings in the memory, and perform the minifying much faster, and created a CSS minifier that produce a small CSS file, much faster, and with much less memory overhead.

This minifier was tested on several CSS files. Feel free to download it and use it. If there is any file that not been minify correctly, send it to me, and I will try to improve the minifier.

CssMinifier.cs (9.59 kb)

Currently rated 4.9 by 12 people

  • Currently 4.916667/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Categories: C# | Client side | Performance
Posted by Miron on Sunday, June 29, 2008 4:48 AM
Permalink | Comments (19) | Post RSSRSS comment feed

Update to my compression module to compress third party scripts

My last version of the compression module was working great and able to compress and cache pages, WebResources, CSS and JavaScripts files. It have one problem (that similiar to most of the compression modules you can find). To compress the javascripts files, you have to modify the way you register them and change their links to something like that: 

<script type="text/javascript" src="/Scripts/utils.js">

needs to became 

<script type="text/javascript" src="Scripts/jslib.axd?d=~/Scripts/utils.js">

It is not so hard work to do, but it became useless when you use third party controls as 'Telerik' (RadControls)  and force it to doesn't use it's scripts as WebResources. In such case, the controls 'Injects' their scripts links into the HTML code and you can't modify them as needed to let the compression handler to compress it.  In the new version of my compression component, I added a ResponseFilter that parse the Scripts links in the HTML and convert them into 'compressable' links. By default, this option is disabled in the compression module. To enable it (if you use such third party controls), just add the attribute compressThirdParityScripts="true" to the compression configuration.

Full implementation instructions can be found here: Compression module implementation 

Latest code can be downloaded from: http://www.codeplex.com/MbCompression

Currently rated 4.8 by 5 people

  • Currently 4.8/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Posted by Miron on Friday, February 22, 2008 4:15 AM
Permalink | Comments (7) | Post RSSRSS comment feed