How to increase performance of XmlReaders / JsonReaders and ListStores

[Algiano]

Hi,

I've put together a short article which may be of use. Not sure if this is the right place to post it, but considering the performance enhancements I've managed to get, I thought I would share this :)

http://www.sambastream.com/blogs/agiannone/29-05-09/high-performance-gxt-gwt-applications-coding-java-javascript

Cheers,
Ale

[Algiano]

Any comments?

[mgoerdes]

Hi,

thanks for this article. I tried to use your results to improve the performance of our application, and therefore had some problems with RPC.

What I did was, that I modified the RPCMap of GXT in order to use a FastStringMap instead of a HashMap there. Unfortunatly I got a java.lang.UnsatisfiedLinkError: com.google.gwt.user.client.ui.FastStringMap.init().

To avoid the error I finally modified the RPCMap as attached, and it works quite nice. Do you see another possibility for this implementation?

The benefit of this would be, that every BaseModel, which is created (on client or on server-side) uses the FastStringMap on client-side.

@GXT-Dev-Team: could something like that be usefull in the GXT-standard?

Regards,
Mark

13978

[Algiano]

Ah yes! Good point.

We didn't actually need to implement the RPC maps which means we simply removed that from the the BaseModel. However, if I were to implement the RPCMap I would probably do it in the same way you have.

Another thing to note is that FastStringMap is optimised to have String type keys.

Do you mind if I add this information to my article to make it more complete? and have you noticed improvements in performance?

Thanks,
Ale

[mgoerdes]

Yes, you can add it to your blog if you want to. I did not do any benchmarking, but I have the impression, that it is faster. I have a TreePanel with a Filter, and there > 10.000 gets are made on the models, which are displayed in the tree, when using the filter. This is much faster now, and does not produce a "Script takes to long" error anymore.

[Algiano]

Thanks for that - when I get a minute I'll add a comment relating to the RPCMaps.

By the way - it's worth mentioning that the FastStringMap requries a string as a key.

[sven]

Thanks for all your researches. I am going to look into this for GXT2. I also have another idea of how to make it fast ;)

[Algiano]

Excellent! Any sneak preview on what these changes are? :)

[sven]

I added a new type of map which uses a hashmap internly if used on serverside and a jso if used on client. It is faster. Will go live with the next commit to trunk

[sven]

Just commited that to SVN for GXT2

[mgoerdes]

Just saw your changes in the trunk, thanks for the quick implementation.

But what I saw was, that you use the Map interface in the RPCMap. This behaviour of this could lead to, what was observed in the following Blog (see differences between 3 and 4):

http://development.lombardi.com/?p=95

What do you think about that? Maybe its because they use Map instead of Map<String, Object>?

[Algiano]

I was just going to point that out.

Using a Map is quicker than using a HashMap but it's not quite as quick as using the FastStringMap - however, the FastStringMap has the limitation that the keys used have to be of type String so it may not be a viable option.

On the other hand, I have got to say that I've very rarely used non-string types as keys for my ModelData.

By the way - that article is very good! The benchmark differences are quite outstanding!

[sven]

The FastMap only uses String as keys. You can use FastMap<Object> map = new FastMap<Object>.

I did many performance tests and i couldnt get it faster with not extending the abstract map class.

[Algiano]

Yes - that's the problem I mentioned earlier - FastStringMap is literally only for String keys.

It may be worth creating two different sets of ModelData objects - one set optimised for String keys with lightning fast performance and one set optimised for any other type of key?

I think it might be worth doing this as the FastStringMap is 5 - 7 times faster than the Map.

This way users who are using String only keys will get a huge increase in performance and people using other types of keys will get a good increase in performance.

[sven]

FastMap is only supporting String as keys ;)

[Algiano]

FastMap is only supporting String as keys ;)

Yes - I am aware of that, mentioned it earlier :)

What I was suggesting was two create two sets of ModelData:

1) One optimised for String keys using FastStringMap
2) One optimised for any object type as a key using a Map

So you could have, for example:

1) BaseStringModelData - using FastSTringMap
2) BaseModelData - using Map

where BaseStringModelData only accepts Strings as keys and BaseModelData accepts any type of object.

The reason I say this is that the performance of executing a FastStringMap is 7 times that of executing a standard Map.

This would enable developers to choose which type of ModelData they wish to use based on their requirements.

What do you recon?

[sven]

Have you done tests with FastMap? It is 50 times faster for me in IE and 10 times in FF. We are overriding any method from AbstractMap.

I did tests with Map<Object> map = new FastMap<Object> and FastMap<Object> map = new FastMap<Object>. They were equalfast. I dont get your point here.

[sven]

Also note that the blogpost is about GWT 1.5. Things can have changed to GWT 1.6

[Algiano]

Have you tried comparing the FastMap with the FastStringMap?

I thought the FastStringMap was optimised further for String keys but I may be wrong as I haven't run any tests to compare FastMap and FastStringMap.

p.s. that is a pretty incredible gain in performance! :)


I haven't started using GWT 1.6 yet so I haven't looked to see if they have changed their implementations of these classes.

[sven]

I thought the FastStringMap was optimised further for String keys but I may be wrong as I haven't run any tests to compare FastMap and FastStringMap.

No. It is only fast because it is storing the data in a JSO.

I did a small testcase for you:

Map map1 = new HashMap();
Map<String, Object> map2 = new HashMap<String, Object> ();
FastMap<Object> map3 = new FastMap<Object>();
Map<String, Object> map4 = new FastMap<Object>();
LonFastStringMap<Object> map5 = new LonFastStringMap<Object>();
Map<String, Object> map6 = new LonFastStringMap<Object>();

in FF3 i get:

elapsed1=815
elapsed2=770
elapsed3=124
elapsed4=124
elapsed5=145
elapsed6=1091

So my FastMap is even faster ;)

in IE8 i get:

elapsed1=964
elapsed2=2253
elapsed3=292
elapsed4=295
elapsed5=329
elapsed6=641

and again my FastMap is faster ;)

[sven]

I used the testcase from the blogpost with is not really a good one.

[Algiano]

Cool! Those times are very very good! :-)

How does your FastMap implementation differ compared to the original FastStringMap?

Is FastMap one of the google ones? (haven't seen it...)

I'd be interested in switching my implementation to use that FastMap instead of FastStringMap now! :)

[sven]

No it is something own.

FastMap can be used also on serverside. Internally it decides where to store the data. If you run it on a client it safes the data in a JSO, on serverside it safes the data in a HashMap ( we dont have JSO there).

I rebuild the complete mapinterface on a jso.

[Algiano]

No it is something own.

FastMap can be used also on serverside. Internally it decides where to store the data. If you run it on a client it safes the data in a JSO, on serverside it safes the data in a HashMap ( we dont have JSO there).

I rebuild the complete mapinterface on a jso.


Ahhh! Fantastic!

Can't wait to see it in action...

Thanks for including this in the build - I think it will make a serious difference :-)

[sven]

This is only part of GXT2. I also changed all intern maps which used a string as key to use fastmap.

[Algiano]

Yes - that's what I meant to say - thanks for including it in the GXT 2 build...

And now that I know that this has been applied across all HashMap instances I can't wait to use GXT 2!! :)

It will be faster than Flash Gordon!

[sven]

It is not on all, but on most. Sometimes we use somthing else than a string as key. It wont work there. But this cases are really rare.

[Algiano]

Cool - I'm sure those exceptional cases will not impact performance too much - if most of it now runs on FastMap we should still see some excellent increases in performance :)

If we come across anything else in our development journey I'll let you know...

[sven]

I was able to make it even faster:

IE8:

elapsed1=1049
elapsed2=2018
elapsed3=134
elapsed4=134
elapsed5=353
elapsed6=709

FF3:

elapsed1=1108
elapsed2=1158
elapsed3=86
elapsed4=90
elapsed5=161
elapsed6=616

Chrome2:

elapsed1=237
elapsed2=235
elapsed3=20
elapsed4=20
elapsed5=108
elapsed6=157

[sven]

IE6:

elapsed1=3205
elapsed2=4336
elapsed3=341
elapsed4=330
elapsed5=1370
elapsed6=2285

[Algiano]

20 ms!! :o

I love Chrome! How did you manage to improve the performance further?

[sven]

I optimized the JSNI code. That was the last idea i had to make it faster. But i guess we already have it almost as fast as possible if not already as fast as possible ;)

[sven]

Changes are in SVN

[Algiano]

Sven - are there any planned release dates for GXT 2.0?

[Algiano]

Sven - is there any chance that this will be implemented in version 1.2.5 for user's who will remain on this library for longer? Alternatively is there any way we can make them aware of these potential improvements so that if they stay o nthe old library they know how to improve the performance of their Readers, etc??

Thanks,
Ale