file != NULL does not mean it's valid. Since Eina_File is
a basic eina type a magic check is still better than nothing.
It can avoid doing eina_file_dup() on a closed file for instance.
This "fixes" a crash in eina_file_close with invalid files.
Now I can go hunt the root cause...
In C we need this to make clear that we really do not accept parameters.
Found by the smatch source code matcher. I had run and fixed this before
but it seems to creep in again over time.
Brought up by running smatch. We have way to many of such things in tree though
to fix them all without annoying a lot of people. I will just stop here.
Summary:
Since eina_model was dropped some years ago.
Also a few other points where related stuff is just commented out.
Reviewers: iscaro, barbieri
Reviewed By: barbieri
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4442
@fix
Summary: add ARG_NONNULL to eina_log* APIs for Eina_Log_Domain * parameter that is always in use, can not be NULL.
Reviewers: cedric, Hermet, myoungwoon, NikaWhite
Reviewed By: NikaWhite
Subscribers: t.naumenko, jpeg
Differential Revision: https://phab.enlightenment.org/D4426
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Func _eina_file_win32_first_file try to find the first file in directory
but if any file not found the file handler stay open, and func will
return error. But in this case while handle is open impossible to do
any actions. For example call eina_file_ls for empty folder, func will
return error and fold folder open. And if we try to remove this folder
Windows only mark it to delete, and remove it after the process is
complete.
Solution: close handler in error case.
Summary:
fix warnings while generating documents
- end of file while inside a group (eina_util.h)
- missing title after \defgroup
- ignoring title "Ecore_Con_Lib_Group" that does not match old title
Reviewers: Hermet
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4420
Summary:
the new iterator represents the order from the elements of the original
iterator, elements where the filter callback return false will be
skipped.
The container of this iterator is the original iterator.
Test Plan: Just run `make check` there is a testcase
Reviewers: cedric, jpeg, raster, herdsman
Differential Revision: https://phab.enlightenment.org/D4417
Seems to me there is little benefit of inlining this function, but this
also had a pervert effect on Windows and C++ with some recent mingw
versions. Mingw failed its implementation of pthread_cleanup_pop(). It
does not compile when compiled in C++. There is a type mismatch that is
caught by the compiler, and everything goes nuts...
This made the EFL build fail because some files of ecore_win32 are C++
sources, and they require Eina... so this macro appears in a C++ code
indirectly, because of its inlining.
By removing the inlining, this build issue is fixed. Will also fix
builds of other programs that would have used Eina.h in their C++
programs :)
this will make a freeq bypass that is enabled by using valgrind or env
var not affect a freeq that has manually changed its queue count max
or mem max. these now become explicit deferred freeers.
this checks for clock_gettime + CLOCK_MONOTONIC or CLOCK_REALTIME at
evlog init to avoid a cmp+brang and l1 instr cache hit every get.
slightly less overhead when this is on.
this runs a 1000hz (or as best the kernel will allow) polling system
monitor thread that will logg the cpu frequencies of all cores (linux
only) as well as cpu usage per thread. this leads to much more
information able to be logged from an efl app (any efl app).
@feature
Summary: Add checking on NULL like in other API in module, to avoid segmentation fault
Reviewers: NikaWhite, cedric
Reviewed By: cedric
Subscribers: myoungwoon, jpeg
Differential Revision: https://phab.enlightenment.org/D4383
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
so i have been doing some profiling on my rpi3 ... and it seems
memcmp() is like the number one top used function - especially running
e in wayland compositor mode. it uses accoring to perf top about 9-15%
of samples (samples are not adding up to 100%). no - i cant seem to
get a call graph because all that happens is the whole kernel locks up
solid if i try, so i can only get the leaf node call stats. what
function was currently active at the sample time. memcmp is the
biggest by far. 2-3 times anything else.
13.47% libarmmem.so [.] memcmp
6.43% libevas.so.1.18.99 [.] _evas_render_phase1_object_pro
4.74% libevas.so.1.18.99 [.] evas_render_updates_internal.c
2.84% libeo.so.1.18.99 [.] _eo_obj_pointer_get
2.49% libevas.so.1.18.99 [.] evas_render_updates_internal_l
2.03% libpthread-2.24.so [.] pthread_getspecific
1.61% libeo.so.1.18.99 [.] efl_data_scope_get
1.60% libevas.so.1.18.99 [.] _evas_event_object_list_raw_in
1.54% libevas.so.1.18.99 [.] evas_object_smart_changed_get
1.32% libgcc_s.so.1 [.] __udivsi3
1.21% libevas.so.1.18.99 [.] evas_object_is_active
1.14% libc-2.24.so [.] malloc
0.96% libevas.so.1.18.99 [.] evas_render_mapped
0.85% libeo.so.1.18.99 [.] efl_isa
yeah. it's perf. it's sampling so not 100% accurate, but close to
"good enough" for the bigger stuff. so interestingly memcmp() is
actually in a special library/module (libarmmem.so) and is a REAL
function call. so doing memcmp's for small bits of memory ESPECIALLY
when we know their size in advance is not great. i am not sure our own
use of memcmp() is the actual culprit because even with this patch
memcmp still is right up there. we use it for stringshare which is
harder to remove as stringshare has variable sized memory blobs to
compare.
but the point remains - memcmp() is an ACTUAL function call. even on
x86 (i checked the assembly). and replacing it with a static inline
custom comparer is better. in fact i did that and benchmarked it as a
sample case for eina_tiler which has 4 ints (16 bytes) to compare
every time. i also compiled to assembly on x86 to inspect and make sure
things made sense.
the text color compare was just comparing 4 bytes as a color (an int
worth) which was silly to use memcmp on as it could just cast to an
int and do a == b. the map was a little more evil as it was 2 ptrs
plus 2 bitfields, but the way bitfields work means i can assume the
last byte is both bitfields combined. i can be a little more evil for
the rect tests as 4 ints compared is the same as comparing 2 long
longs (64bit types). yes. don't get pedantic. all platforms efl works
on work this way and this is a base assumption in efl and it's true
everywhere worth talking about.
yes - i tried __int128 too. it was not faster on x86 anyway and can't
compile on armv7. in my speed tests on x86-64, comparing 2 rects by
casting to a struct of 2 long long's and comparing just those is 70%
faster than comapring 4 ints. and the 2 long longs is 360% faster than
a memcmp. on arm (my rpi3) the long long is 12% faster than the 4 ints,
and it is 226% faster than a memcmp().
it'd be best if we didnt even have to compare at all, but with these
algorithms we do, so doing it faster is better.
we probably should nuke all the memcmp's we have that are not of large
bits of memory or variable sized bits of memory.
i set breakpoints for memcmp and found at least a chunk in efl. but
also it seems the vc4 driver was also doing it too. i have no idea how
much memory it was doing this to and it may ultimately be the biggest
culprit here, BUT we may as well reduce our overhead since i've found
this anyway. less "false positives" when hunting problems.
why am i doing this? i'm setting framerate hiccups. eg like we drop 3,
5 or 10 frames, then drop another bunch, then go back to smooth, then
this hiccup again. finding out WHAT is causing that hiccup is hard. i
can only SEE the hiccups on my rpi3 - not on x86. i am not so sure
it's cpufreq bouncing about as i've locked cpu to 600mhz and it still
happens. it's something else. maybe something we are polling? maybe
it's something in our drm/kms backend? maybe its in the vc4 drivers or
kernel parts? i have no idea. trying to hunt this is hard, but this is
important as this is something that possibly is affecting everyone but
other hw is fast enough to hide it...
in the meantime find and optimize what i find along the way.
@optimize
this adds eina_freeq api's for c land for deferring freeing of
pointers and can be used a s a simple copy & paste drop-in for free()
just to "do this later". the pointer will eveentually be freed as
eina_shutdown will free the main free queue and this will in turn free
everything in it. as long as the main lo0op keeps pumping things will
og on the queue and then be freed from it. free queues have limits so
if they get full they will clear out old pointers and free them so it
won't grow without bound. the default max is 1mb of data or 16384
items whichever limit is hit first and at that point the oldest item
will be freed to make room for the newest. the mainloop whenever it
finishes idle enterers will add an idler to spin and free while idle.
the sizes can be tuned and aruged about as to what defaults should be.
this also allows for better memory debugging too by being able to fill
freed memory with patterns if its small enough etc. etc.
@feature
following my commit for ecore_init(), do that for eina_init() as well,
sometimes it's hard to find the vars and their meaning without looking
at the code.
in eina_file we are using eina_hash, eina_hash is using eina_rbtree, so
we should ensure that rbtree is shutted down AFTER file is shutted down.
fix T4753
It's not because the bug with __builtin_prefetch is inside
clang/llvm that we must break the build for people who prefer it
over gcc. As soon as a non-broken version is out, the ifdef must
be either removed (and ask people to update their clang install)
or add a version check based on __clang_xxx__.
Compilation tested with clang 3.8.1 and gcc 6.2.1.
i see a speedup of about 8% over a series of list walking and freeing
functions given this change. it's a small speedup but still not too
shabby just for some prefetches thrown in. ymmv depending on memory
subsystem, memory speed itself, cpu and architecture.
@optimize
this allows you to portably use prefetch compiler builtins. this adds
EINA_PREFETCH(), EINA_PREFETCH_WRITE(), EINA_PREFETCH_NOCACHE() and
EINA_PREFETCH_NOCACHE_WRITE() macros to do this that are "nothing" if
your compiler doesnt support it. of course it also requires your
compielr compile instructions for your architecture and it can only do
so if the architecture it compiles for has these instructions, so be
aware.
@feat
this moves a lot of logic that is rare away from the linear/flat asm
path of code so we et fewer l1 cache misses when executing chuncks of
our code. this also reduces the code size and takes some funcs like in
eina_inline_lock_posix.x and makes them real functions to reduce code
size thus better l1 cache usage - only for new/free of locks.
spinlocks, semaphores etc. as these will have no advantage being
inlined but simply bloat out code size instead.
overall this actually reduces efl lib binary sizes 0.4%, so that's a
good sign.
this passes make check and i think i got it right... let me know if i
didn't. i'm also not sure i should just keep the static inlines and
not make the formerly static inline funcs full EAPI ones now... good q.
CPUs can be turned off after boot leading to a sparse mapping of core ids.
For example, if I turn off the first four cores on an exynos 5422 (these
are the low speed cores) then the high speed cores are still numbered 4-7
but there are only 4 cores present.
In that situation using affinity_core % num_cpus will prevent ever being
able to set affinity at all.
Just remove the pointless check and let the user set whatever core id they
want.
In a big.LITTLE ARM system cores can have different capabilities. This
gives an internal API that randomly returns the core id of any of the
system's fastest cores.
On systems where all cores are the same, it will return any available core.
If we don't have cpufreq support we just return 0
Cedric BAIL
Marcel Hollerbach
Jean-Philippe Andre
Stefan Schmidt
Bruno Dilly
Artem Popov
Gustavo Sverzut Barbieri
Vyacheslav Reutskiy
Jee-Yong Um
Carsten Haitzler
Jean Guyomarc'h
Derek Foreman
Jee-Yong Um