Benjamin Otte
2008-Oct-30 16:01 UTC
[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
> 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