Summary:
ecore_evas: remove debug
eina: unregister log level when done with
Fixes a constant memory leak.
eina: introduce EINA_HOT and EINA_COLD
These attributes respectivelly expand to __attribute__ ((hot)) and
__attribute__ ((cold)) when available. They allow to mark functions are
being hot/cold (frequently used or not) as well as to qualify labels
within a function (likely/unlikely branches).
eo: speed-up generated calls by removing call cache
The call cache needed to by thread-local, to avoid concurrency issues.
Problem with TLS is that is adds an extra overhead, which appears to be
greater than the optimization the cache provides.
Op is naturally atomic, because it is an unsigned integer. As such, it
cannot be tempered with while another thread is reading it. When
entering the generated function, the first operation done is reading
'op'. If we have concurrency, we will have access sequences returning
either EFL_NOOP or a VALID op, because 'op' is not set until the very
end of the function, when everything has been computed. As such, we now
use the 'op' atomic integer to instore a lock-free/wait-free mechanism,
which allows to drop the TLS nature of the cache, speeding up the access
to the cache, and therefore making functions execute faster.
We don't test anymore the generation count. This can be put as a
limitation. If means that if you call efl_object_shutdown() and
re-initialize it later with different data, opcodes will be invalid.
I am not sure there is any usecase for this to ever happen.
We could move all the caches in a dedicated section, that can be
overwritten after a call to efl_object_shutdown(), but I am not sure it
will be very portable.
Benchmark: mean over 3 executions of
ELM_TEST_AUTOBOUNCE=100 time elementary_test -to genlist
```
BEFORE AFTER
------------------------------------------------------------
time (ns) 11114111647.0 9147676220.0
frames 2872.3333333333335 2904.6666666666665
time per frame (ns) 3869364.6666666665 3149535.3333333335
user time (s) 11.096666666666666 9.22
cpu (%) 22.666666666666668 18.333333333333332
```
Ref T6580
Reviewers: raster, cedric
Subscribers: cedric, jpeg
Maniphest Tasks: T6580
Differential Revision: https://phab.enlightenment.org/D5738
this fixes a bug with scrollable panel not being blocked
when it is closed. scroll is blocked in _anim_stop_cb()
which is called after elm_interface_scrollable_region_bring_in().
but if panel content is already at the target position, _anim_stop_cb()
is not called. so there is a need to check content's position and
handle the exceptional case.
this fixes a bug with scrollable panel not being blocked
when it is closed. scroll is blocked in _anim_stop_cb(),
which is called after elm_interface_scrollable_region_bring_in().
but if panel content is already at the target position, _anim_stop_cb()
is not called. so there is a need to check content's position and
handle the exceptional case.
there is a need to check if callback functions already exist or not
before adding or deleting them, because they are added or deleted
at two points:
in _elm_panel_scrollable_set() and _elm_panel_elm_widget_disable().
Summary:
when the popup is deleted, some EVAS_CALLBACK_DEL callback functions
try to use already freed objects.
reorder free sequence to prevent it.
Test Plan:
1. elementary_test -to popup
2. check 'Enable popup scroll'
3. open several popup test and click Close button.
4. check that there are no error message
Reviewers: Jaehyun_Cho, bu5hm4n
Reviewed By: Jaehyun_Cho
Subscribers: cedric, jpeg, herb
Differential Revision: https://phab.enlightenment.org/D5730
The compiler is not to happy about having this tick in the warning
message. Switch to the more formal can not and be done with it.
menu_cxx_example_01.cc:3:26: warning: missing terminating ' character
If ecore_file_monitor_del is called inside the file monitor callback function,
eina_list found from monitor_hash would be freed. (You can check this inside
eina_hash_list_remove.)
Then, EINA_LIST_FOREACH makes one more for loop with invalid eina_list pointer.
EINA_LIST_FOREACH_SAFE can prevent from this problem.
Summary: This monitor window is just used to receive events when mutiple
monitors are available. it should not be managed by the ecore loop
(creation and destruction events), so initting it earlier means
ecore_win32 attaches less memory/overhead to it as it's just being
used for notifications for devices.
Test Plan: DrMemory to check used memory
Reviewers: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D5736
After a function pointer validation branch got enabled, it turned
out that people have been writing obviously incorrect eo files
all along.
So while I have no idea if this is logically fully correct, at
least EFL builds again now...
cc @thiepha
Gcc complains here due to _wl_default_seat_id_get not accepting a
'const' Evas_Object, so to avoid the warning just case it to a normal
Evas_Object when passing in.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
otherwise we get a complaint for everty time some audio needs/wants to
play and that's just noisy and ugly, so only do it once - the first
time sndfile/pulse are being loaded and it fails.
Send visible/hidden signal when text/content are realized.
This feature is already implemented in genlist widget,
for reacting dynamically in item layout depending on their
text/content realizations.
we can't sensibly use things like massif to track memory if we bypass
itr with mmaping -1 fd anonymous memory... so if built with valgrind
support and running under valgrind, use malloc/calloc and free so
these tools actually do something useful for these bits of memory.
osmesa needs llvm. llvm apparently just by dlopening or linking to the
lib (libLLVM...) gets you 3.5mb of dirty pages just in this lib. that's
a whole lib entirely dirty pages. odd and horrible. in fact once i
stoppd dlopening OSMesa all the time on engine init (and only when gl
is needed)... the amount of dirty pages went from 17208 to 8860.
that's a whopping drop of 8mb! 8mb saved! in fact just dlopening
osmesa and doing the other gl init stuff led to more anonymuse
mappings with dirty pages. 2 of them (2072k and 2076k) which baffled
me as that didn't seem like heap or efl's own data. these disappeared
along with libLLVM-5.0.so (3520k + 60k dirty pages). we stopped
linking/loading libedit (12k dirty), libglapi (20k dirty),
libLLVM-5.0 (3580k dirty), libncursesw (72k dirty),
libOSMesa.so (260k dirty), libtinfo (20k dirty). ... or at least
stopped until absolutely needed. total 17208k of dirty pages went down
to 8860.
my test case was just launching terminology (and doing nothing with it).
@fix memory bloating