* bug#1229: generate-new-buffer-name could be more efficient
[not found] <e3tzb3pzkm.fsf@fencepost.gnu.org>
@ 2012-07-03 7:33 ` Glenn Morris
2012-07-03 13:58 ` Stefan Monnier
0 siblings, 1 reply; 4+ messages in thread
From: Glenn Morris @ 2012-07-03 7:33 UTC (permalink / raw
To: 1229
Stefan Monnier wrote:
> When generate-new-buffer-name is called for a user-visible buffer,
> fixing this would be probably too much trouble for too little
> benefit. But for internal buffers, whose precise name doesn't
> actually matter, we should use a different strategy, where we
> immediately start by adding a random suffix to the buffer name, so as
> to avoid conflicts.
Something like the following? Timing results for me with this change:
(let ((start (current-time)))
(dotimes (i 500)
(generate-new-buffer "a"))
(float-time (time-since start)))
-> 0.55 seconds (and 4.3 seconds the next time)
Repeating with " a" instead of "a", it takes 0.025 seconds.
*** src/lisp.h 2012-06-30 09:13:54 +0000
--- src/lisp.h 2012-07-03 02:41:45 +0000
***************
*** 2473,2478 ****
--- 2473,2479 ----
EXFUN (Fremhash, 2);
EXFUN (Fidentity, 1);
+ EXFUN (Frandom, 1);
EXFUN (Flength, 1);
EXFUN (Fappend, MANY);
EXFUN (Fconcat, MANY);
*** src/buffer.c 2012-07-03 03:57:52 +0000
--- src/buffer.c 2012-07-03 07:24:11 +0000
***************
*** 838,847 ****
Otherwise modify name by appending `<NUMBER>', incrementing NUMBER
\(starting at 2) until an unused name is found, and then return that name.
Optional second argument IGNORE specifies a name that is okay to use (if
! it is in the sequence to be tried) even if a buffer with that name exists. */)
(register Lisp_Object name, Lisp_Object ignore)
{
! register Lisp_Object gentemp, tem;
ptrdiff_t count;
char number[INT_BUFSIZE_BOUND (ptrdiff_t) + sizeof "<>"];
--- 838,852 ----
Otherwise modify name by appending `<NUMBER>', incrementing NUMBER
\(starting at 2) until an unused name is found, and then return that name.
Optional second argument IGNORE specifies a name that is okay to use (if
! it is in the sequence to be tried) even if a buffer with that name exists.
!
! If NAME begins with a space (i.e., a buffer that is not normally
! visible to users), then for efficiency reasons if buffer NAME
! already exists a random number is first appended to NAME, to speed
! up finding a new buffer. */)
(register Lisp_Object name, Lisp_Object ignore)
{
! register Lisp_Object gentemp, tem, tem2;
ptrdiff_t count;
char number[INT_BUFSIZE_BOUND (ptrdiff_t) + sizeof "<>"];
***************
*** 854,864 ****
if (NILP (tem))
return name;
count = 1;
while (1)
{
sprintf (number, "<%"pD"d>", ++count);
! gentemp = concat2 (name, build_string (number));
tem = Fstring_equal (gentemp, ignore);
if (!NILP (tem))
return gentemp;
--- 859,880 ----
if (NILP (tem))
return name;
+ if (!strncmp (SSDATA (name), " ", 1))
+ {
+ sprintf (number, "-%"pD"d", Frandom (make_number (999999)));
+ tem2 = concat2 (name, build_string (number));
+ tem = Fget_buffer (tem2);
+ if (NILP (tem))
+ return tem2;
+ }
+ else
+ tem2 = name;
+
count = 1;
while (1)
{
sprintf (number, "<%"pD"d>", ++count);
! gentemp = concat2 (tem2, build_string (number));
tem = Fstring_equal (gentemp, ignore);
if (!NILP (tem))
return gentemp;
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#1229: generate-new-buffer-name could be more efficient
2012-07-03 7:33 ` bug#1229: generate-new-buffer-name could be more efficient Glenn Morris
@ 2012-07-03 13:58 ` Stefan Monnier
2012-07-03 17:21 ` Glenn Morris
2012-07-03 17:27 ` Stefan Monnier
0 siblings, 2 replies; 4+ messages in thread
From: Stefan Monnier @ 2012-07-03 13:58 UTC (permalink / raw
To: Glenn Morris; +Cc: 1229
> Something like the following?
Yes.
> + sprintf (number, "-%"pD"d", Frandom (make_number (999999)));
I don't like this arbitrary constant. Maybe we could use something
like "N * Flength (Vbuffer_alist)".
Stefan
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#1229: generate-new-buffer-name could be more efficient
2012-07-03 13:58 ` Stefan Monnier
@ 2012-07-03 17:21 ` Glenn Morris
2012-07-03 17:27 ` Stefan Monnier
1 sibling, 0 replies; 4+ messages in thread
From: Glenn Morris @ 2012-07-03 17:21 UTC (permalink / raw
To: Stefan Monnier; +Cc: 1229
Stefan Monnier wrote:
>> + sprintf (number, "-%"pD"d", Frandom (make_number (999999)));
>
> I don't like this arbitrary constant. Maybe we could use something
> like "N * Flength (Vbuffer_alist)".
OK; though personally I don't see that it matters. IIUC, mkstemp,
fileio.c's make_temp_name, etc, all use a finite number of possible
random states, and they don't have the <2>... fallback that
generate-new-buffer-name does.
(Another option is to extract the random scheme that make_temp_name uses
to a separate function and use that here too.)
What do you want the arbitrary constant N to be ? :)
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#1229: generate-new-buffer-name could be more efficient
2012-07-03 13:58 ` Stefan Monnier
2012-07-03 17:21 ` Glenn Morris
@ 2012-07-03 17:27 ` Stefan Monnier
1 sibling, 0 replies; 4+ messages in thread
From: Stefan Monnier @ 2012-07-03 17:27 UTC (permalink / raw
To: Glenn Morris; +Cc: 1229
>> Something like the following?
> Yes.
>> + sprintf (number, "-%"pD"d", Frandom (make_number (999999)));
> I don't like this arbitrary constant. Maybe we could use something
> like "N * Flength (Vbuffer_alist)".
Not sure what I was smoking, sorry, just ignore that comment.
Stefan
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-07-03 17:27 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <e3tzb3pzkm.fsf@fencepost.gnu.org>
2012-07-03 7:33 ` bug#1229: generate-new-buffer-name could be more efficient Glenn Morris
2012-07-03 13:58 ` Stefan Monnier
2012-07-03 17:21 ` Glenn Morris
2012-07-03 17:27 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).