[Kde-bindings] KDE/kdebindings/csharp

[Richard Dale]

On Wednesday 30 July 2008 16:14:38 Arno Rehn wrote:
> On Wednesday 30 July 2008 15:17:49 Richard Dale wrote:
> > On Wednesday 30 July 2008 14:03:25 Arno Rehn wrote:
> > > On Wednesday 30 July 2008 14:31:23 Richard Dale wrote:
> > > > On Wednesday 30 July 2008 01:01:28 Arno Rehn wrote:
> > > > > On Monday 28 July 2008 20:13:05 Richard Dale wrote:
> > > > > > On Saturday 26 July 2008 20:56:44 Arno Rehn wrote:
> > > > > > > SVN commit 838125 by arnorehn:
> > > > > > >
> > > > > > > * Use qobject_cast in the KWrite example.
> > > > > > > * If CreateInstance() doesn't find a type, it now replaces the
> > > > > > > last '.' with a '+' and tries again to find nested classes.
> > > > > >
> > > > > > I don't think this is the best way to fix the problem. I think we
> > > > > > need a Dictionary from a C++ classname to the C# type. Then
> > > > > > another Dictionary that we already have to get from the Type to
> > > > > > details about how to construct the instance.
> > > > > >
> > > > > > I'm not sure we need to have a Dictionary or QHash that goes from
> > > > > > the C++ classname to  the C# classname, and then finally get the
> > > > > > Type by walking through all the loaded assemblies. I would have
> > > > > > thought that was pretty slow apart from problems with '+'s and
> > > > > > '.'s in  the classname paths.
> > > > >
> > > > > Yes, it's definitely not the best solution. I think we should fix
> > > > > the problem directly in SmokeBinding::className(). We could
> > > > > dynamically replace every '::' with a '.' and then check if the
> > > > > type exists in C#. If it doesn't, replace the last '.' with '+' and
> > > > > so on... At the end we cache the result. We could then get rid of
> > > > > the static classname-hash initialization in every module, too.
> > > >
> > > > We've always got the C++ class name first in order to have retrieved
> > > > the C# one from the SmokeBinding::className() hash. So I think we
> > > > should be directly retrieving the C# Type given the C++ name. Maybe
> > > > it is useful to have a human readable version of the C# class name
> > > > that we can retrieve from the C++ name, and the binding.className()
> > > > call could do that. I think we should walk through the classes in a
> > > > newly loaded assembly looking for SmokeClass attributes, and build up
> > > > a Dictionary of C++ names <--> C# types that way.
> > >
> > > I thought about that first, too. But walking through all the classes of
> > > a assembly via reflection is quite slow and I don't know if the
> > > additional overhead is worth it. Actually only around half of the
> > > classes in a module, if not less, will really be used in a project, I
> > > think.
> >
> > I think we need to do some actual timing measurements to find out how
> > much loads would be slowed down. Maybe we could build a table of C++
> > names vs. C# types at compile time. Anyway, I think the hack we have at
> > the moment is ok until we've thought about this a bit more.
>
> I've written a small test app which loads the qt-dotnet, kde-dotnet and
> plasma assemblies and checks for types with the SmokeClass attribute
> (source attached). At the end it prints the milliseconds it took to walk
> through all the types. On my desktop machine it takes around 73 ms to do
> that, so it's not that bad after all (though that's quite recent hardware).
Interesting. My 'rule of thumb' for the longest acceptable time for when 
things are loading would be 250 ms - more than that and the user will start 
to notice. So 73 ms seems OK to me. Although, your benchmark doesn't time 
putting things into a Dictionary<string, Type> (surely quick?). What was very 
slow as far as I can remember, was creating entries in the Dictionary<Type, 
SmokeClassData> smokeClassCache in SmokeMarshallers.cs, and so I think they 
should still only be added on demand.

-- Richard