From: Keith David Bershatsky <esq@lawlist.com>
To: Alex Gramiak <agrambot@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Universal functions to manage multiple window caches.
Date: Thu, 18 Apr 2019 18:44:59 -0700 [thread overview]
Message-ID: <m2zhomvkdg.wl%esq@lawlist.com> (raw)
Thank you, Alex, for the suggestions to better organize the new cache design.
I did not stop to think that calling memset on every window update potentially carried with it a cost to performance, and the OCD side of my brain wanted to continuously tidy things up. I will just need to keep reminding myself that its okay to leave garbage data where it is so long as I steer clear of it by using a counter. :)
I created a minimal working example based upon my interpretation of how to use your sample struct. Was it your intention that each main cache would be defined as follows (and the MWE being nth 0 below):
1. TEMP flavor: w->mc_elts[0]
2. MC flavor: w->mc_elts[1]
3. CH flavor: w->mc_elts[2]
4. FC flavor: w->mc_elts[3]
if (BUFFERP (w->contents)
&& !NILP (BVAR (XBUFFER (w->contents), crosshairs)))
{
/* Increase the size of the array. */
if (w->mc_elts_allocated == 0)
{
++w->mc_nelts;
int old_alloc = w->mc_elts_allocated;
int new_elts = w->mc_nelts - w->mc_elts_allocated;
w->mc_elts = xpalloc (w->mc_elts, &w->mc_elts_allocated,
new_elts, INT_MAX, sizeof *w->mc_elts);
memset (w->mc_elts + old_alloc, 0,
(w->mc_elts_allocated - old_alloc) * sizeof *w->mc_elts);
}
int max_elts = 25000;
w->mc_elts->used += (w->mc_elts->used < max_elts)
? 100
: 0;
/* Increase the size of the array. */
if (w->mc_elts->allocated < w->mc_elts->used
&& w->mc_elts->used < max_elts)
{
int old_alloc = w->mc_elts->allocated;
int new_elts = w->mc_elts->used - w->mc_elts->allocated;
w->mc_elts->caches = xpalloc (w->mc_elts->caches, &w->mc_elts->allocated,
new_elts, INT_MAX, sizeof *w->mc_elts->caches);
memset (w->mc_elts->caches + old_alloc, 0,
(w->mc_elts->allocated - old_alloc) * sizeof *w->mc_elts->caches);
for (int elt = 0; elt < w->mc_elts->used; ++elt)
{
w->mc_elts[0].caches[elt].x = elt;
double red = elt;
w->mc_elts[0].caches[elt].foreground.red = red;
w->mc_elts[0].caches[elt].enabled_p = true;
}
}
fprintf (stderr, "w->mc_elts->used (%d) | w->mc_elts->allocated (%d) | w->mc_elts[0].caches[99].x (%d)\n",
w->mc_elts->used, w->mc_elts->allocated, w->mc_elts[0].caches[99].x);
}
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> Date: [04-18-2019 14:02:15] <18 Apr 2019 15:02:15 -0600>
> From: Alex Gramiak <agrambot@gmail.com>
> To: Keith David Bershatsky <esq@lawlist.com>
> Cc: Emacs Devel <emacs-devel@gnu.org>
> Subject: Re: Universal functions to manage multiple window caches.
>
> Keith David Bershatsky <esq@lawlist.com> writes:
>
> > I am working on feature requests 22873 (multiple fake cursors) and 17684 (crosshairs that track the cursor position).
> >
> > window.h defines four different caches of fake cursors, with the only difference between them being their names:
> >
> > struct multiple_cursors_cache *temp_elts;
> > ptrdiff_t temp_elts_allocated;
> > int temp_nelts;
> >
> > struct multiple_cursors_cache *mc_elts;
> > ptrdiff_t mc_elts_allocated;
> > int mc_nelts;
> >
> > struct multiple_cursors_cache *ch_elts;
> > ptrdiff_t ch_elts_allocated;
> > int ch_nelts;
> >
> > struct multiple_cursors_cache *fc_elts;
> > ptrdiff_t fc_elts_allocated;
> > int fc_nelts;
>
> Each of the four could just be structs themselves. Something like:
>
> struct multiple_cursor_cache
> {
> ptrdiff_t allocated;
> ptrdiff_t used;
> struct items
> {
> int x;
> int fx;
> int y;
> int fy;
> int hpos;
> int vpos;
> int wd;
> int h;
> int cursor_type;
> int cursor_width;
> struct RGB
> {
> double red;
> double green;
> double blue;
> } foreground, background;
> bool active_p;
> int glyph_flavor;
> bool enabled_p;
> } *caches;
> };
>
> If you need to differentiate them in a helper procedure, you can add an
> enum element to the outermost struct.
>
> P.S. Why do you need to memset the used portion of the caches on every
> window update? I would think that just setting the used/*_nelts count
> would be sufficient as long as you make sure not to go past that and
> access garbage data.
next reply other threads:[~2019-04-19 1:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-19 1:44 Keith David Bershatsky [this message]
2019-04-19 13:59 ` Universal functions to manage multiple window caches Alex Gramiak
-- strict thread matches above, loose matches on Subject: below --
2019-04-20 20:29 Keith David Bershatsky
2019-04-20 6:58 Keith David Bershatsky
2019-04-20 17:17 ` Alex Gramiak
2019-04-18 3:17 Keith David Bershatsky
2019-04-17 20:03 Keith David Bershatsky
2019-04-18 21:02 ` Alex Gramiak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2zhomvkdg.wl%esq@lawlist.com \
--to=esq@lawlist.com \
--cc=agrambot@gmail.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.