This is faster in most cases, and to be honest, should be much faster
than it is. I don't understand why there's no better directive to mark a
variable as *really* important thread storage that is used all the time.
We don't really need the eo_id most of the time, and when we do, it's
very easy to get it. It's better if we just don't save the eo_id on the
stack, and just save if it's an object or a class instead.
It seems that the idea behind that optimisation, is to save object data
fetching when calling functions implemented by the object's class inside
functions implemented by the object's class. This should be rare enough
not to worth the upkeep, memory reads and memory writes, especially
since for all cases apart of mixins (for which this optimisation won't
work for anyway), the upkeep is more costly than fetching the data
again.
removing the klass member meant removing hooks and keeping cache small
but that meant not using it. this meand if the object is not an obj...
i removed the:
call->obj = _eo_class_id_get(call->klass);
line - seemed harmless/pointless. apparently not. so put it back but
use the klass there in local vars and not in call as it's not there
(and not needed).
fix.
we pass both the callcache and the op id - both are static and filled
in at runtime, so merge them into the same struct. this should lead to
better alignment/padding with the offset array and the next slot and
op fields, probably saving about 4-8 bytes of rame per method with no
downsides. also pass in only cache ptr, not both cache ptr and opid -
less passing of stuff around and should be better.
BEWARE! this breaks eo ABI. _eo_call_resolve and _eo_data_scope_get
are 2 of the biggest cpu users in eo. they easily consume like 10-15%
cpu between them on tests that drive a lot of api - like simply
scrolling a genlist around. this is a lot of overhead for efl. this
fixes that to make them far leaner. In fact this got an overall 10%
cpu usage drop and that includes all of the actual rendering, and code
work, so this would drop the eo overhead of these functions incredibly
low. using this much cpu just on doing call marshalling is a bug and
thus - this is a fix, but ... with an abi break to boot. more abi
breaks may happen before release to try and get them all in this
release so we don't have to do them again later.
note i actually tested 4, 3, 2, and 1 cache slots, and 1 was the
fastest. 2 was very close behind and then it got worse. all were
better than with no cache though.
benchmark test method:
export ELM_ENGINE=gl
export ELM_TEST_AUTOBOUNCE=1
while [ 1 ]; do sync; sync; sync; time elementary_test -to genlist;
sleep 1; done
take the 2nd to the 8th results (7 runs) and total up system and user
time. copmpare this to the same without the cache. with the cache cpu
time used is 90.3% of the cpu time used without - thus a win. at least
in my tests.
@fix
so we do a bit of error handling like does a stack fail to allocate,
does setting the tls var fail, have the stack frames been nulled or
not allocated, etc. - these acutally cost every call because they mean
some extra compare and branches, but ore because they cause a lot fo
extra code to be generated, thus polluting instruction cache with code
and cacheline fetches of code that we rarely take - if ever.
every if () and DBG, ERR etc. does cost something. in really hotpath
code like this, i think it's best we realize that these checks will
basically never be triggered, because if a stack fails to grow... we
likely alreayd blew our REAL stack for the C/C++ side and that can't
allocate anymore and has already just crashed (no magic message there -
just segv). so in this case i think this checking is pointless and
just costs us rather than gets us anything.
This causes a significant speed up (around 10% here) and is definitely
worth it. The way it's done lets the compiler cache the value across
different eo_do calls, and across the parts of eo_do. Start and end.
This breaks ABI.
This may look like an insignificant change, but it doubles the speed of
this function, and since this function is called so often, it actually
improves my benchmarks by around 8%.
This breaks ABI in a harmless way, and it will give us the ability to
drastically improve Eo in the future without breaking ABI again, thus
allowing us to declare Eo stable for this release if we choose to.
We use function names instead of function pointers of Windows, because
of dll import/export issues (more in a comment in eo.c). Before this
commit we were comparing the pointers to the strings instead of the
content in some of the places, which caused op desc lookup not to work.
This fixes that.
Thanks to vtorri for his assistance.
@fix
This removes code that became dead in commit:
389c6d35f2
The commit doesn't explain why we don't shrink or grow when using mmap,
but this is how it is. No reason to keep old code there.
CID 1240224
@fix
As described by Carsten in his email to edev ML titled:
"[E-devel] eo stability - i think we need to postpone that"
with the switch to Eo2 we significantly increased our usage of RW memory
pages, and thus significantly increased our memory usage when running
multiple applications.
The problem was that during the migration to Eo2 the op id cache and the
op description arrays were merged, causing the op description arrays to
no longer be RO. This patch enables users of Eo (mainly Eolian) to
declare those arrays as const (RO) again, saving that memory.
There might be performance implications with this patch. I had to remove
the op desc array sorting, and I used a hash table for the lookup. I
think the op desc sorting doesn't really affect performance because that
array is seldom accessed and is usually pretty short. The hash table
is not a problem either, because it's behind the scenes, so it can be
changed to a more efficient data structure if the hash table is not good
enough. The hash table itself is also rarely accessed, so it's mostly
about memory.
Please keep an eye for any bugs, performance or excessive memory usage.
I believe this should be better on all fronts.
This commit *BREAKS ABI*.
@fix
This hasn't been used for a while. Since we are going to break Eo a bit anyway
it's a good opportunity to drop this.
This may cause a slight performance issues with legacy events, such as
smart callbacks. This shouldn't really be a problem as we've migrated away from
them. If it does, we need to migrate the remaining parts. Only relevant
for callbacks that are added before the classes are created, which
shouldn't be possible except for smart, only for old evas callbacks.
After this change, parent_set assigns a ref, so for example:
obj = eo_add(CLASS, parent); /* Ref is 1 */
eo_do(obj, eo_parent_set(parent2)); /* Ref is 1 */
eo_ref(obj); /* Ref is 2 */
eo_do(obj, eo_parent_set(NULL)); /* Ref is 1, giving the ref to NULL */
eo_do(obj, eo_parent_set(parent)); /* Ref is 1 */
This is following a discussion on the ML about commit
8689d54471.
@feature
@fix
XXX: Given EFL usage of objects, construction is a perfectly valid thing
to do. we shouldn't complain about it as handling a NULL obj creation is
the job of the caller. a perfect example here is ecore_con and ecore_ipc
where you create a con or ipc obj then set up type/destination/port and
the finalize of the constructor does the actual connect and thus this
fails or succeeds based on if service is there.
until there is a better solution - don't complain here.
This is heavily based on a patch by Vincent Torri. I just refactored it
a bit so it doesn't break ABI on Linux, only on Windows (where it was
broken anyway).
This patch changes things so on Windows, functions are looked up only
based on their name. Because of the indirection (and export/import
tables) windows does, this is the only reasonable way to make it work.
You should always use curly brackets. Especially when the inside statement
has its own curlys. This can be confusing and has already lead to bugs in
many projects.
While unrefing twice works, it's cleaner to unref the ref we
have and delete normally. It will handle parnet detachments in
a nicer way, and is just more correct.
This is another cleanup in perparation for the Eo stable release.
This is no longer needed thanks to the proper error reporting with
eo_constructor()'s new return value.
The finalizer change cleans it up a bit so it catches more cases/issues.
This also means that the finalizer cleans up the object in all cases,
and not only some.
@feature.
From now on, constructors should return a value, usually the object
being worked on, or NULL (if the constructor failed). This can also
be used for implementing singletons, by just always returning the same
object from the constructor.
This is one of the final steps towards stabilizing Eo.
@feature
As discussed on IRC and ML. We are in a feature freeze phase, and this
patch is not essential. Furthermore, this patch was never discussed.
This reverts commit 537c7fe9e3.
This affects eo_do() and eo_add() that used to use the ({}) GCCism.
Following a discussion with Peter de Ridder after my talk at FOSDEM,
we've decided to reopen the GCCism (works with other gcc compatible
compilers like clang and intelc) discussion, and after a bit of back and
forth it was decided to make things more portable, at the cost of ease
of use.
For example:
if (eo_do(obj, visible_get()))
is no longer allowed, the portable alternative
Eina_Bool tmp;
if (eo_do_ret(obj, tmp, visible_get()))
is to be used instead.
However:
eo_do(obj, a = a_get(), b = b_get(), bool_set(!bool_get))
are still allowed and OK.
eo_do(obj, if (a_get()) return;);
is no longer allowed, but:
eo_do(obj, if (a_get()) something());
is still allowed.
For clarity, this commit only incorporates the Eo changes, and not the
EFL changes to make the efl conform with this change.
Thanks again to Peter de Ridder for triggering this important discussion
which led to this change.
The header.id was masked before using it as index in the _eo_classes
array and was not unmasked when used.
It hasn't caused segfault (by sheer luck) but was wrong.
@fix
So I don't really understand why the code was not there before, but it resulted
in my experiment of making a combobox for elementary just impossible. Now it
work at least.
For some reason, they were normal functions instead of eo functions,
which makes them harder to bind, less safe, and just wrong.
This commit fixes that.
Now it's more clear and consistent. This commit complements the previous
eo_add commit (a7560dbc61).
Now eo_add should be matched with eo_del
eo_ref with eo_unref
eo_add_ref with eo_unref + eo_del
Essentially, the change is that if you have the ref to an object, you
need to unref it. Thus making ref/unref unneeded for most people who use
things (carefully) in c. If however, you would like to delete an object
previously created by you, you should eo_del (counter-part to eo_add).
It's still recommended you ref/unref when dealing with objects in
scopes, as you can't know when an object might just get deleted as a
by-product of another call.
This fixes an issue found by JackDanielZ.
Before this change eo_add() used to create an object with 1 ref, and if
the object had a parent, a second ref.
Now, eo_add() always returns an object with 1 ref, and eo_add_ref()
preserves the old behaviour (for bindings).
eo_unref now un-parents if refcount is 0, and eo_del() is an alias for
eo_unref (will change to be a way to ensure an object is dead and goes
to zombie-land even if still refed).
This moves the mainloop check inside the function. There was never need
for it to be in client code (i.e a header/macro).
This is better suited inside eo_do_start because this is a macro some
bindings have to re-implement, and we definitely don't want it to be any
more complicated than it has to be.
This breaks ABI and makes elm 1.12 depend on efl 1.11. This is not an issue
as because of eolian and interfaces it's already the case.
eina_tls_get is really slow, having a fast path for the main loop does really
help us right now. It is also unlikely that slowing down a little bit the use
of eo in thread is going to have any impact on application speed any time soon.
I win a +10% on expedite benchmark compared to without.
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This enables checking if an object is being created, or has already been
finalized. This is useful in functions that you want to allow
only during the creation phase (i.e inside the eo_add()).
Comp objects are rare, and since we allow using classes as interfaces,
we end up allocating a lot of memory for something we don't even use.
That's why it was a linked list in the first place, and that's why it
should remain a list.
This is almost a complete revert. I reverted the code itself, and the
intent (use of array instead of list), but not the tests, or the new
return value added to comp_detach, which is useful.
This reverts commit ef09ef7489.
This function lets you hook at the end of eo_add and override it for a
class. This is essentially the first step towards killing custom
constructors. Instead of having a custom constructor, you should just
do:
eo_add(CLASS, parent, a_set(3), b_set("eou"));
eo_constructor is called at the beginning for pre-init things.
eo_finalize is called at the end, for actually finalizing and doing
things. This cleans up the API and possibly saves a lot of things that
would have been stupid and slow in the past, like loading an elm widget
with an existing theme, and then changing the theme.
** This breaks Eo ABI, please recompile elementary and everything else that
creates eo objects.
@feature
Match function names when the API pointer is out of range.
Reviewed by TAsn and modified according to his comments :)
Differential Revision: https://phab.enlightenment.org/D876
this fixes and eo2 problem where when callstack grows (or shrinks)
and realloc nas to relocate memory, the frame ptrs like fptr become
invalid and all sorts of hell ensues.
this uses mmap so blowing the stack will segv, not scribble over
memory, also its separated from malloc heap, and now big enough to not
need to size ... ever (1024 entries).
It's now completely valid to do:
a = eo_do(obj, a_get());
or:
b = eo_do(obj, a_set(1), b_get());
Also, the default return value for eo2 functions is now also returned
when the object is invalid, not just when the object does not match
class.
It's a small refactor that fixed both issues at once.
@feature
@fix
create/destroy tls key (_eo2_call_stack_key) at eo_init()/eo_shutdown().
use _eo2_call_stack_get() to allocate the stack when required.
register _eo2_call_stack_free() as eina_tls_cb_new() delete callback.
eo_class_new() returns NULL on error in _eo2_class_funcs_set().
it covers: NULL API func, API redefined, dich func override,
overriding non-existing fct.
as op descs are sorted, we can't output fct indexes in error msgs, but
as they are sorted using api_fct as key, we can detect multiple usage of
the same api_fct which leads to an unpredictable call to whatever is
returned by _eo2_api_op_id_get()->_eo2_api_desc_get().
it is still possible to instanciate an object of a not well defined class.
a mixin class must not inherit
- _eo2_api_desc_get()
accept NULL klass param
EO_CLASS_TYPE_REGULAR_NO_INSTANT is an acceptable extension class type for
- _eo2_class_funcs_set() do not shout if parent is NULL
there is no more difference in class or regular functions prototypes and definitions
- eo2_api_op_id_get() uses _eo_is_a_class() at runtime
- add 'void *class_data EINA_UNUSED' parameter to eo2_base class functions
- Eo2_Op_Call_Data.klass is kept only for eo2_hook_call_pre end eo2_hook_call_post,
but could be removed easily
in the EPAI, don't show that Eo* could be IDs.
in the implementation, use klass_id and obj_id
if you know or want it to be a class or an object,
use eo_id in general cases.
We want to have normal functions as non-default constructors, not va_arg
ones. What we should do is split the object creation to two parts again.
The creation, the constructing (changes using the macro) and the
verification/end part that checks the constructor has been called.
This reverts commit 2ff2ce1894f173b306a896bda595e1a7768c074d.
to protect us against bad use of break, goto, return ... in eo2_do,
we use __attribute__((cleanup(eo2_do_end))) to ensure that eo2_do_end()
is called whatever.
at class elaboration, sort the op descriptions using the function pointer.
when calling a function, do a dichotomic search in the
class op descriptions to find the corresponding OP_ID,
then keep it in a static variable.
All classes are allowed, because all classes can be used as interfaces in
order to override behaviour. This is especially needed for mixins and broke
the eo2 tests.
Was fien on the normal path but missing on the error path. Also remove
the spurious break after the return. Would never be reached. Looks like
a copy and paste bug to me.
CID 1187638
This patch sets the one before most significant bit on for classes. This
means that class ids are now very big, compared to the old ids which
were growing small integers (1, 2, 3...).
This makes accidental passing of integers (corrupted obj pointers) less
common.
@feature
as we don't support multiple composites of the same class,
and know at class elaboration how many composites we should have,
we can create the composites array and pack it at the end of the object.
@fix
mixins data offsets are stored in Eo_Extension_Data_Offset[],
if the constructed class is a mixin, do not reserve space for its
private data, the class is in mixins list and will be handled at
Eo_Extension_Data_Offset computation.
see _eo_data_scope_get(...) for private data retrieval
as we don't support multiple composites of the same class,
and know at class elaboration how many composites we should have,
we can create the composites array and pack it at the end of the object.
eo_composite_attach fail if the class of the composite is not
listed in the parent class extensions, or if there is already a
composite of the same class. The later because calls are
forwarded to the first responding composite, see _eo_op_internal().
This reverts commit ee1b0833ed
I did it manually because the code changed too much.
We actually want this type, it makes things more clear and easier to
understand.
this is the first step on the road to remove class specific EAPI from Eo.h
using this handle we will know if a Eo* is a class or an object pointer
Conflicts:
src/lib/eo/eo.c
The goal would be to replace the smart children list and friends. The
problem is that they differ in content. Smart children and Eo children are
the same, but Elm children and them differ. If I put this function as a
virtual, it would be possible to override the list of children and if we
start using it in Evas render loop, that could result in "weird" behavior.
I have added the use of a simplified Eina_Trash mempool kind of feature
to have some fast path for allocation if we start using it in Evas render
loop.
extn_data_size is not equal to extn_data_off,
current class data size and data offset must be substracted first
elementary_test bubble peak usage goes from 13.7 MiB to 12.5 MiB
We want to introduce a new mechanism concerning the data of the Eo
objects.
The goal is to improve the memory management by defragmenting the memory
banks used by the Eo objects. The first phase has been done by raster
and consists in allocating the objects into a separate memory region
that the one used by malloc. So now, we know where our objects are
located.
Now, moving objects means moving data of objects. The issue we have here
is that a lot of data pointers are stored into data of other objects,
e.g Evas Object data into lists for rendering...
We need a way to reference the data and eo_data_get doesn't provide us
that. So we need to improve the API for data extraction by requesting
from the developer if the data will be stored or not. Five functions are
supplied:
- eo_data_scope_get: no referencing, the data pointer is no more used after
exiting the function.
- eo_data_ref: reference the data of the object. It means that while the
data is referenced, the object cannot be moved.
- eo_data_xref: reference the data of the object but for debug purpose,
we associate the objects that references. Same behavior as eo_data_ref
for non-debug.
- eo_data_unref: unreference the data of an object.
- eo_data_xunref: unreference the data of an object previously
referenced by another object.
I deprecated the eo_data_get function. Most of the time,
eo_data_scope_get needs to be used.
In the next patches, I changed the eo_data_get to the corresponding
functions, according to the usage of the data pointer.
The next step is to find all the places in the code where the data is
stored but not yet referenced. This will be done by:
- requesting from every object to unreference all data to other objects.
- moving all the objects from one region to another
- requesting from every object to rerefenrence the data.
- debugging by hunting the segmentation faults and other weird
creatures.
Summary: This feature replaces Eo pointers with ids to prevent bad usage
or reuse of these pointers. It doesn't change API.
The mechanism uses tables storing the real pointers to the objects.
See the src/lib/eo/eo_ptr_indirection.c file for more details on the
mechanism.
Because of the way eo is dispatching method calls of objects the usual
error log you get if you mix up objects or try to call non-existent
methods is:
ERR<12404>:eo lib/eo/eo.c:362 _eo_dov_internal() Can't find func for op
0x24 (ecore_audio_obj_in:ECORE_AUDIO_OBJ_IN_SUB_ID_SPEED_GET) for class
'ecore_audio_obj_out_pulse'. Aborting.
Of course the problem is not really in lib/eo/eo.c, but in the function
calling eo_do()
Now the macros pass source file and line number on to the _internal
functions so we can log where the error originally happened:
ERR<1938>:eo lib/eo/eo.c:362 _eo_dov_internal() in
lib/ecore_audio/ecore_audio_obj_out_pulse.c:119: Can't find func for op
0x24 (ecore_audio_obj_in:ECORE_AUDIO_OBJ_IN_SUB_ID_SPEED_GET) for class
'ecore_audio_obj_out_pulse'. Aborting.
This makes debugging with eo a lot easier.
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
Tom Hacohen
Carsten Haitzler
Jaehwan Kim
Nicolas Aguirre
Avi Levin
Jérémy Zurcher
Cedric BAIL
Mike Blumenkrantz
Daniel Kolesa
Jean Guyomarc'h
Jean-Philippe Andre
Cedric BAIL
Guillaume Friloux
Cedric Bail
Daniel Zaoui
Cedric Bail
Stefan Schmidt
Daniel Willmann
Daniel Juyung Seo