Incrementing pointer *ps once is faster than computing string[i] for each
time we need it.
Bug fix: For the remote possibility of a crazy-long comment section that
overflows int, this fix can also return a value larger than sizeof(int).
Signed-off-by: Jose Da Silva
---
libavcodec/xpmdec.c | 27
Incrementing pointer *pr once is faster than computing reject[j] for each
time we need it.
Signed-off-by: Jose Da Silva
---
libavcodec/xpmdec.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/libavcodec/xpmdec.c b/libavcodec/xpmdec.c
index 66a9a8008c..7b3d3a7ff5
Test string==0 once before looping. This avoids testing 'string!=0'
i times inside the for i loop, (plus more checks for comments).
Test reject==0 once before looping. This avoids testing 'reject!=0'
i*[strlen(reject)+1] times inside the for j loop string.
Signed-o
t;int".
Signed-off-by: Jose Da Silva
---
libavcodec/xpmdec.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/libavcodec/xpmdec.c b/libavcodec/xpmdec.c
index 922dfc0f67..5aab46c52d 100644
--- a/libavcodec/xpmdec.c
+++ b/libavcodec/xpmdec.c
@@ -191,
On February 24, 2021 05:56:17 AM Moritz Barsnick wrote:
> On Mon, Feb 22, 2021 at 20:32:14 -0800, Jose Da Silva wrote:
> > -for (i = 0; string && string[i]; i++) {
> > +if (string == 0)
>
> "if (!string)" is the preferred style for pointers.
Wor
Incrementing pointer *ps once is faster than computing string[i] for each
time we need it.
Bug fix: For the remote possibility of a crazy-long comment section that
overflows int, this fix can also return a value larger than sizeof(int).
Signed-off-by: Jose Da Silva
---
libavcodec/xpmdec.c | 27
Test string==0 once before looping. Avoid testing inside the loop.
Test reject==0 once before looping. Avoid testing inside the loop.
Signed-off-by: Jose Da Silva
---
libavcodec/xpmdec.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/libavcodec/xpmdec.c b
t;int".
Signed-off-by: Jose Da Silva
---
libavcodec/xpmdec.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/libavcodec/xpmdec.c b/libavcodec/xpmdec.c
index 922dfc0f67..5aab46c52d 100644
--- a/libavcodec/xpmdec.c
+++ b/libavcodec/xpmdec.c
@@ -191,
Incrementing pointer *pr once is faster than computing reject[j] for each
time we need it.
Signed-off-by: Jose Da Silva
---
libavcodec/xpmdec.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/libavcodec/xpmdec.c b/libavcodec/xpmdec.c
index 92a568041c..be5277e637
Some compilers are very intuitive, and others are not so much, so let's
pre-compute the variables e and keylen outside the for loop. Ensuring a
minor speed increase regardless of if compiler is smart enough to solve
this improvement for itself, or not.
Signed-off-by: Joe Da Silva
---
libavcodec/
If we test for {0..9} first, we have tested for 10/16th of all possible
characters first and avoid testing the remaining 6/16th of all possible
characters, which can be either 6/16th lowercase or 6/16th uppercase.
Signed-off-by: Joe Da Silva
---
libavcodec/xbmdec.c | 10 +-
1 file change
Replace av_isxdigit(*ptr) and convert(*ptr) with get_nibble(*ptr) which
returns a valid nibble=={0x00..0x0f} or false==255 for all other values.
This way we only need to work with *ptr once instead of twice.
Removing inline av_isxdigit(x) functions also shrinks executable size.
Signed-off-by: Joe
Minor speed increase, end is calculated before entering parse_str_int(),
so let's take advantage of the value and avoid recalculating twice more.
This also allows parse_str_int() to work with file size larger than int.
Signed-off-by: Joe Da Silva
---
libavcodec/xbmdec.c | 8 +++-
1 file chan
This is an incredibly busy dev list.
- pretty easy to miss a message in the noise.
Thanks for the FYI.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffm
I've run into some bugs where I was downloading a bunch of data and began
seeing weird hiccups. For example, javascript promises to allow you to push
some very long lines of data, but the hiccups I saw was with data larger
than 2k in length (windows) pushed out of a child process stdout piped in
Two minor memory improvements.
First bug reduces memory needed to about 6/7 the needed amount, which
allows you to host almost 7 pictures in the same memory needed for 6
Second is a recalculation of the total additional memory for headers etc.
size = avctx->height x (linesize * 6 + 1) + (31+32+3
There is a minor bug in xbm encode which adds a trailing comma at the end
of data. This isn't a big problem, but it would be nicer to be more
technically true to an array of data (by not including the last comma).
This bug fixes the output from something like this (having 4 values):
static unsig
Small memory reduction which uses approx 6/7th total memory.
Assuming \n is 2bytes, we first need {32+33+40+5}=110
but we also need to include the terminating zero => 110+1 = 111 (bug-fix).
Then assuming \n is 2bytes, data requires => height * (linesize * 6 + 2)
For example, " 0x00, 0x11, 0x22,\n"
18 matches
Mail list logo
