[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: SmartWrappers, all tests OK.
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-04-06 21:23:21
[Download RAW message or body]

   Hi!

On Sun, Apr 02, 2000 at 10:05:22PM +0100, Nicolas Brodu wrote:
> I've added more from my pooltest.cc, but since they all PASS there's not much
> use for now (apart from showing they PASS...)
Well, it helps to easily test if something breaks when making changes.

> > Also, the other "shoulds" should be verified. But probably speed is the
> > most important problem right now.
> 
> I'm not sure what 'fast creatable' means now that we have lazy create. But apart
> from this, the only way to know for the others is to port the current code.

I meant copy constructors and assignments should be fast. Well, I have added
another test that is kind of that: Calling

D afunc(D arg)
{
    arg.value(42);
    return arg;
}                                                                               

which involves a D copy constructor (for arg). The current results are

      generic inheritance test ... PASSED
  nullity and error conditions ... PASSED
         proper cache handling ... PASSED
      SmartWrapper as argument ... PASSED
               speed for calls ... PASSED
  -> old 23193688 calls/sec
  -> new 21773238 calls/sec
speed for params & returncodes ... FAIL
  -> old 4109981 calls/sec
  -> new 1717171 calls/sec

which is the result of some bigger optimizations in the _cast section (I
started with 380000 or something like that). The new _cast uses interface IDs
now, which map interfaces to numbers. This is much faster than the old string
code.

Well, if you see something what we could optimize, let me know. I also got
rid of some destructors (strangely, putting a _pool->Dec() into ~SmartWrapper
is slower than putting it in ~A/~B/~C/~D  -- why that?). I only generate
the topmost one (i.e. A in the wrapper.idl hierarchy).

Besides that - I think I'd like to try to port the rest. What I need to still
think/experiment about a bit is whether we should do parameter passing like

D afunc(D arg)

or 

D afunc(D& arg)

the last one solves the speed issue. As I said, it opens the door on the other
hand for incorrect assumptions with parameter passing.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-

[prev in list] [next in list] [prev in thread] [next in thread]