[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_con

[Benjamin Otte]

> 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.
>
Yes, if you only compare allocating a number, you are of course
corect. However, figuring out the type is done with (register & 7) as
opposed to register->type (which requires a memory fetch) and fetching
an object is *(register & ~7) as opposed to *register->object (1 fetch
instead of two). So all in all, the value system should be faster.

> 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.
>
First of all, we do use glib and second, you are only looking at
numbers again. If you use the current SwfdecAsValue, each value takes
12 bytes on a 32bit machine (8 bytes for the value union due to
doubles, 4 bytes for the type). This is 3x as much as a single pointer
for every type but numbers. Numbers now take at most 16 bytes (12 for
the number, 4 for the value) as opposed to 12. Loss of at most 1/3rd.
So unless at least 75% of your values are numbers (and I don't think
this is the case) you gain memory.

> So why we want to enbrace abobe's bug
> here? Why not fix it instead?
>
Because we are writing a Flash player. And for a Flash player these
conditions hold.
Note that the standard we implement is called flashplayer.exe and
everything this standard says is the law. If Flash thinks 1+1 equals
3, it does. We dont do math here, we do Flash.
If any Flash file relies on this behavior, we _must_ replicate it. And
I can see noone who can prove that there's no Flash file relying on a
particular feature.
In fact, I can prove to you that there is a Flash file relying on it.
That file is part of our testsuite.

> And personally I think the old implementation is clearer:)
>
The API is almost completely the same. So there is no clarity problem
- unless you look at the implementation. But that's just 20 lines.

Cheers,
Benjamin