edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Karl Dahlke <eklhad@comcast.net>
To: edbrowse-dev@lists.the-brannons.com
Subject: [Edbrowse-dev] Object identifiers
Date: Mon, 24 Jul 2017 03:03:14 -0400	[thread overview]
Message-ID: <20170624030314.eklhad@comcast.net> (raw)
In-Reply-To: <20170724052529.GB31626@nautica>

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

Now I'm thinking about performance, and that could be a problem.
duktape is allocating and freeing zillions of things all the time, most of them not objects.
duk_get_string, duk_push_string, etc.
Edbrowse is the same way if you look at the code.
So pass all those pointers across and scan through all tags in all open windows against all pointers? I don't think so.
No - I'd have to maintain a watch list in the js process.
My own wrapper around get_heapptr() that says, this is an important pointer that will be linked to an edbrowse tag, keep it in a list.
Then our wrapper around free could scan through this list and 99% of the time it wouldn't match so do nothing.
If it does match then remove it from the watch list and pass it over to edbrowse as a side effect.

To do it right, it's not easy peasy; might be about the same effort is generated IDs,
but the free interceptor might still win the day, primarily because it allows garbage collection to continue, and web pages will not accumulate objects second by second by second.

Karl Dahlke

  parent reply	other threads:[~2017-07-24  7:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-24  0:52 Karl Dahlke
2017-07-24  1:04 ` Chris Brannon
2017-07-24  5:25 ` Dominique Martinet
2017-07-24  6:43   ` Karl Dahlke
2017-07-24  7:49     ` Dominique Martinet
2017-07-24  7:03   ` Karl Dahlke [this message]
2017-07-24  5:43 ` Robert Ransom
2017-07-24 17:45   ` Adam Thompson

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=20170624030314.eklhad@comcast.net \
    --to=eklhad@comcast.net \
    --cc=edbrowse-dev@lists.the-brannons.com \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).