Thread: SV: [Dynapi-Dev] Freeing Memory

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Yes it would be slower.
Bit shifting is faked in Javascript actually. From what I know you are =
actually working with 32 bit ingegers tha whole time...  so the JS =
interpreter actually has to perform an additional operation to work with =
bits... transforming it back and forth , where needed.
I'm 99% sure of this... but this would lead to the question of why they =
bothered putting in bit calculation in the first place...

-----Ursprungligt meddelande-----
Fr=E5n: Jeff Greenberg <je...@we...>
Till: dyn...@li... =
<dyn...@li...>
Datum: den 20 februari 2001 22:23
=C4mne: Re: [Dynapi-Dev] Freeing Memory

>This kind of thing becomes troublesome in javascript.
>
>For instance, bit shifting for multiples of 2 is great.... except that =
all my
>tests show that it offers no advantages, and, in fact, is sometimes =
slower in
>javascript than just multiplying by 2. (If anyone wants to see a demo =
of this I
>will post it on my site).
>
>Lookup tables fair a little better, but their gain over straight =
calculations
>only seems to be about 3 or 4 percent at most (I need to check this =
more
>thouroughly).
>
>
>
>Jeff Greenberg
>je...@we...
>
>Raymond Smith wrote:
>
>> 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] =3D color;
>>     }
>>
>> optimized
>>
>>     int gx,gy,gz,color;  //define globals
>>
>>     void Plot_G(void) {
>>     video_buffer[gx + gy*MEMORY_PITCH] =3D 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+=3D(2*buffer[index++])>10) {
>>     do stuff...
>>     }
>>
>> Optimized
>>
>>     x+=3D(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 =3D 10:
>>     // multiple y_pos by 64
>>     y_pos =3D (y_pos << 6);  //2^6=3D64
>>
>> Similarly,
>>
>>     //to divide y_pos by 8
>>     y_pos =3D (y_pos >> 3); // 1/2^3 =3D 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
>
>
>_______________________________________________
>Dynapi-Dev mailing list
>Dyn...@li...
>http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>