[Swfdec] [Swfdec-commits] 15 commits - doc/swfdec.types swfdec/Makefile.am swfdec/swfdec_amf.c swfdec/swfdec_as_array.c swfdec/swfdec_as_array.h swfdec/swfdec_as_boolean.c swfdec/swfdec_as_boolean.h swfdec/swfdec_as_context.c swfdec/swfdec_as_context.h sw

[zou lunkai]

On Thu, Oct 30, 2008 at 5:45 PM, Benjamin Otte <otte at gnome.org> wrote:
> On Thu, Oct 30, 2008 at 2:59 AM, zou lunkai <zoulunkai at gmail.com> wrote:
>> In ActionScript, primitive numbers are not GC-collected or reference
>> counted, aren't they?
>>
>> What's the good point to make primitive numbers to be heap allocated?
>> Is it overkill?
>>
> Two things:
> 1) Performance and memory footprint - you want the value type to be
> machine size (see every Javascript engine out there). If you put
> doubles into the value type, you need > 8 bytes (8 for the double and
> 2 or 3 for the type description)
>

I like the performance and memory concern. That's one of the main
reason that I asked the question.

But for the performance, swfdec_as_value_set_number() should be much
slower than the good old macros. It involves a memory allocation now.
Even it uses the memory managment developed in glib, the three
layered(Magzine->Slice->system malloc) mechanism which is said to be
more effient than the system default implementation, it's still a big
overhead compared to the old one.  As for the memory footprint,
pointers indeed just need 4bytes on most 32-bits system, but don't
forget that each allocation(including glib) would cost at least
another 4 bytes for internal usage, for pointing to the next available
location in glib or marking the size of the allocated memory in many
other systems.  That is to say, each allocated number(the pointer)
would at least cost 8 bytes. And would be more without using glib.



> 2) This test:
> x = 0/0;
> y = x;
> z = 0/0;
> trace (x == y);
> trace (x == z);
> In somewhat extended form also available as test/trace/equality-nan*.swf
>
>
yes, I'v check that tests and I noticed that weird results before.
see more tests below:

x = 0/0;
y = x;
z = 0/0;
trace (x == y); //true   [1]
trace (x == z); //false  [2]
trace (x >= z); //true   [3]
trace (z >= x); //true   [4]

Note that from(3) and (4), we can also deduct z == x mathematically,
which is conflict with [2].  So why we want to enbrace abobe's bug
here? Why not fix it instead?

And personally I think the old implementation is clearer:)

--zou