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

List:       osflash-sandy
Subject:    [Sandy] 303 performance issue - to Thomas
From:       kiroukou () gmail ! com (Thomas Pfeiffer)
Date:       2008-08-26 7:33:07
Message-ID: aea162c80808260033m77a1f5fel2e95323edfb3ffe () mail ! gmail ! com
[Download RAW message or body]

Ok so we can see the cache has an interesst here.
the bad suprise is that the previous approach seems to be faster due to
previous tests.

Or maybe the slowdown came before these changes? I need to check the svn
log.

Thanks for the tests MAkc :)

2008/8/25 Makc <makc.the.great at gmail.com>

> with sphere results are as expected:
>
> trunk shape3d
>
> 45118
> 44463
> 45399
>
> cache-less shape3d
>
> 48238
> 47942
> 53495
>
> On Mon, Aug 25, 2008 at 4:31 PM, Thomas Pfeiffer <kiroukou at gmail.com>
> wrote:
> > Can you execute the same test with Sphere or any other primitive and make
> > the same report?
> >
> > Thomas
> >
> > 2008/8/25 Thomas Pfeiffer <kiroukou at gmail.com>
> >
> >> Indeed, Box primitive is structured is a way that faces do not share any
> >> vertices, and in that special case, CACHE is slowing down everything :)
> >>
> >> (reminds me that this Box primitive needs to be rewritten...)
> >>
> >> 2008/8/25 Makc <makc.the.great at gmail.com>
> >>
> >> again, similar results for vertex cache in Shape3D:
> >>>
> >>> times with cache:
> >>> 29877
> >>> 33156
> >>> 35544
> >>>
> >>> times with no cache:
> >>> 27482
> >>> 26515
> >>> 31230
> >>>
> >>> this is funny since shape3d cache should actually always hit because
> >>> of same vertices in faces (maybe that's not a case with Box primitive
> >>> ?)
> >>>
> >>> also, times range is very overlapping to conclude anything.
> >>>
> >>> On Mon, Aug 25, 2008 at 3:51 PM, Makc <makc.the.great at gmail.com>
> wrote:
> >>> > thought I'd finally take a look at the main problem in the way of 303
> >>> release.
> >>> >
> >>> > I made my own test from over 100 rotating boxes (maybe not the best
> >>> > idea though), which somewhat confirmed my earlier point on vertex
> >>> > cache in camera - it is totally useless.
> >>> >
> >>> > you see, I added a trace wherever there should have been a hit:
> >>> > if( m_oCache[ l_oVertex ] != null ) { trace ("hit"); continue; }
> >>> >
> >>> > and I saw no hits whatsoever. on the other hand, this trace worked
> every
> >>> time:
> >>> > if( m_oCache )  m_oCache = null;
> >>> > m_oCache = new Dictionary(false); trace ("update");
> >>> >
> >>> > as for numeric tests, I have counted ms for 200 cycles, and results
> >>> were:
> >>> > trunk (cache) - 25277 to 29859
> >>> > no cache - 25328 to 26039
> >>> >
> >>> > this is probably not significant enough to explain whole 303 slowness
> >>> > problem, but I just dont see when would this cache thing work, only
> >>> > perhaps when scene is rendered without change?
> >>> >
> >>>
> >>> _______________________________________________
> >>> Sandy mailing list
> >>> Sandy at osflash.org
> >>> http://osflash.org/mailman/listinfo/sandy_osflash.org
> >>>
> >>
> >>
> > _______________________________________________
> > Sandy mailing list
> > Sandy at osflash.org
> > http://osflash.org/mailman/listinfo/sandy_osflash.org
> >
>
> _______________________________________________
> Sandy mailing list
> Sandy at osflash.org
> http://osflash.org/mailman/listinfo/sandy_osflash.org
>

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