🚀 go-pugleaf

"Mockvichev Nikolai" <mnv@papillon.ru> wrote in message
news:1046752275.599401@fionika.papillon.ru.N.O.S.P.A.M...
> We found that TMemStream.Read(...) equally 2 times slowly than memcpy(...)

This brings up an interesting point...

I haven't profiled it, but from looking at the source of TMemoryStream, it
looks like every time Write(...) is called, there is a potential for the
Capacity property to be increased to precisely enough space to hold the
information that's about to be written.

In other words, the memory potentially gets reallocated on every Write.
Most std::vector implementations, by contrast, will double the capacity of
the vector when you do a push_back rather than merely allocate an additional
/sizeof(value_type)/ bytes.  This is because allocation is typically
*extremely* expensive, and is even more expensive when that memory needs to
be initialized via a copy from an old memory location and followed by a
release of the old buffer.  The net effect is to amortize the cost of
allocation and yield a push_back that takes (amortized) constant time.
Constant time can still be a long time, of course - write a simple loop that
does push_back on a std::vector<DWORD> a thousand times and you'll see what
I mean.

In both TMemoryStream and std::vector, the speed problem isn't the copying
of information into the container, it's the side effect of resizing the
container to accomodate the new data.  A common way to prevent these
problems is to preallocate.  For example, if you are about to do a bunch of
push_backs on std::vector, you would call std::vector::reserve( /n/ ), where
/n/ is a reasonable estimate (or exact value if known) of the number of
elements in the vector *after* the series of push_backs occurs.

With TMemoryStream, you would simply assign a new value to the Capacity
property immediately after construction, thereby preallocating the space you
need.  You can't know the size needed, since JPEG is a rather unpredictable
algorithm in that regard, but you can make a reasonable guess and if you're
capturing the screen repeatedly, you could even track the maximum size
required.

There's only one problem... Capacity is a protected member of TMemoryStream.
So you need to derive from TMemoryStream and expose Capacity:

class TMemoryStreamWithCapacity
  : public TMemoryStream
  {
  public:
    TMemoryStreamWithCapacity
      ( long InitialCapacity = 0 )
      : TMemoryStream( )
      { Capacity = InitialCapacity; }

    __property Capacity; /* expose Capacity property */
  };

Then, in your function:

  static long MaxCap = 0x100000; // 1 Megabyte
    /* Generally I dislike static variables (or
       any variables that have global lifetime),
       but the point here is to show that the
       value is somehow retained between screen
       captures. */

  std::auto_ptr< TMemoryStreamWithCapacity > ms
    ( new TMemoryStreamWithCapacity( MaxCap ) );
    /* Create a TMemoryStreamWithCapacity object,
       tell it to preallocate MaxCap bytes of
       memory. */

  /* Capture Screan, etc... */

  jpg->SaveToStream( ms.get() );
    /* Hopefully TMemoryStreamWithCapacity is
       faster than TMemoryStream since we've
       preallocated :) */

  MaxCap = std::max( ms->Size , MaxCap );
    /* bump up MaxCap if necessary */

--
-- Early Ehlinger CEO, ResPower Inc - Toll-Free : 866-737-7697 --
- RenderFarm - Lightwave , 3dSMax , Bryce , Maya , AfterEffects -
--- www.respower.com -- 500+ GHz Starting At USD$0.50/GHz*Hour --
----------------- SuperComputing For the Masses! ----------------
"I'm so busy programming my computer to let me be lazy, I never
get any rest!" - John Kaster