Re: [Dynapi-Dev] Freeing Memory

[Doug M. <do...@cr...>]

Another tip is not to over do it with the 'snazz'.
The problem with my orgigional Demo site was that I used DynAPI wherever
possible.
I have found that one can use simple HTML or plain javascript
in a lot of places (such as for roll-over menus, or 'dynamic' content).
Which in turn speeds up the site and resduces the mem-footprint.

Doug
----- Original Message -----
From: "Raymond Smith" <dst...@or...>
To: <dyn...@li...>
Sent: Tuesday, February 20, 2001 12:51 PM
Subject: Re: [Dynapi-Dev] Freeing Memory


> I'm really beginning to think there are two sides to this issue.
>
> 1)  Design Methodology.
> 2)  Code Optimization.
>
> 1) Eytan eluded to this here, "and then nullify them nothing happens but
> when you recreate them still the memory stays stable".  Today most sites
are
> page based, and I think within a common site URL browsers attempt to "hold
> history active" till you leave to an all new destination, then purge
memory.
>
> Everything I have been trying to do is based on using the DynAPI to create
a
> single interface linked to a dynamically created, updated and evolving
site.
> Think of the JS as providing "interface" only.  Then you would use dynamic
> content engines to pump new content into "reusable components" using
set"xx"
> methods (heck you could even reskin an object on the fly).  This is the
> direction the web is moving anyway with CSS and XML anyway.
>
> There's no reason you couldn't initialize a series of display widgets then
> call them in, resize them and modify content based on user activities.  I
> think page based browsing + DynAPI (with any level of pizzazz) is a recipe
> for failure.  It will eventually overload the system since every page is
> going to want it's own widget set.  Design would be based on creating
sites
> with as tight a "widget depth (how many total layers)" as possible.  Reuse
> widgets (if possible) prior to creating new instances of a prototype.
>
> 2) Optimization.  I came from a game developer www.angelstudios.com.  I
was
> COO and I found the business of "making games" slow and boring.  The idea
of
> waiting and working 2 years to see if you have a winner to only see the
> "bounty" get slyly skimmed into the publishers pockets grows old fast).
> Hence, I left the Industry for the fast paced insanity of the web.  But
game
> developers are optimization freaks, they have to be.
>
> I did a little research (I wasn't a programmer, I made sure they didn't
eat
> to many Twinkies during a specified month because at Angel we bought all
the
> Twinkies for our employees; kept them coding longer), and just from a
> "tricks of the trade standpoint" our code could be significantly optimized
> with a skew towards the Pentium processor set.  I'm sure with additional
> research we could learn even more.  Here's what I found so far:
>
> a)  API's, in general, are non-optimizied.  DirectX works (as an API)
> because it was designed to be as "thin" as possible.
>
> b)  Use global variables.  Don't use parameters for allot of time-critical
> functions, instead use a global parameter passing area.  Example:
>
>     void Plot(init x, init y, init color) {
>     // plots a pixel on the screen
>     video_buffer{x +y*MEMORY_PITCH] = color;
>     }
>
> optimized
>
>     int gx,gy,gz,color;  //define globals
>
>     void Plot_G(void) {
>     video_buffer[gx + gy*MEMORY_PITCH] = color;
>     }
>
> I realize we are an API, but implementing aspects of this where
appropriate
> will help.
>
> 2)  Always use 32-bit variables rather then 8- or 16-bit.  The Pentium and
> later processors are all 32-bit.  This means they don't like 8- or 16-bit
> data words, and in fact, smaller data can slow them down due to caching
and
> other related memory anomalies.  Example:
>
>     struct CPOINT {
>     short x,y;
>     unsigned char c;
>     }
>
> Optimized
>
>     struct CPOINT {
>     int x,y;
>     int c;
>     }
>
> I don't think this applies a great deal to the current API but I am
sharing
> it anyway.
>
> 3)  Program in a RISC-like (reduced instruction set computer) manner.  In
> other words make code simple rather then complex.  Pentium class
processors
> like simple instructions rather then complex ones.  Longer simpler code is
> faster then short complex code structures.  Example:
>
>     if ((x+=(2*buffer[index++])>10) {
>     do stuff...
>     }
>
> Optimized
>
>     x+=(2*buffer[index]);
>     index++;
>
>     if (x>10) {
>     do stuff...
>     }
>
> We do sin here a bit....
>
> 4)  Use binary shifts for simple multiplication of integers by powers of
2.
> Since all data in a computer is stored in a binary form, shifting the bit
> pattern to the left or right is equivalent to multiplication or division.
> Example:
>
>     int y_pos = 10:
>     // multiple y_pos by 64
>     y_pos = (y_pos << 6);  //2^6=64
>
> Similarly,
>
>     //to divide y_pos by 8
>     y_pos = (y_pos >> 3); // 1/2^3 = 1/8
>
> Disadvantage... confusing code to some.
>
> 5)  Write efficient algorithms.
>
> 6)  Don't write complex data structures for simple objects.
>
> 7)  Don't go crazy with inheritance and layers of software.  Keep the base
> as lean as possible.
>
> 8)   The Pentium-class processors use an internal data and code cache.  Be
> aware of this, and try to keep the size of your functions relatively small
> so they can fit into the cache (16KB-32KB+).  Store data in an accessible
> way, it minimizes cache thrashing and main memory or secondary cache
access,
> which is 10 times slower than the internal cache.
>
> 9) Use precomputed "look-up tables" when possible.
>
>
> So, I think that freeing memory and optimizing speed will be the marriage
of
> a quality site design/interface and a well constructed code base to draw
> from.  While some users will elect to take a more conventional path I
think
> this will ultimately lead the the best "final result".  But hey!  I'm just
a
> designer...
>
> Ray
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev


---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01