[Kde-bindings] KDE/kdebindings/csharp

[Arno Rehn]

On Wednesday 30 July 2008 18:12:51 Richard Dale wrote:
> 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.
Just tested it again with inserting entries into a Dictionary, and the very 
first time I ran the app, I got a result of 297 ms. Though all runs after that 
were around 75 ms. I think it takes some time to load the assemblies into 
memory - after that it's quite fast, regardless of whether we insert stuff 
into a Dictionary or not.

-- 
Arno Rehn
arno at arnorehn.de