Re: [Evolution-hackers] ORBit performance tweak
On Mon, 2002-04-22 at 01:22, Not Zed wrote: Yeah i did something similar when purifying and quantifying on the Solaris box - I thought 20% of total cpu for initialising 64 objects was a bit much, I guess the timing/scheduling is different enough on solaris to make the algorithm really not work well. I think on Linux we just use /dev/random, that's why you don't need the patch. I wonder who this should go to ... Michael Meeks, who now maintains ORBit. Unfortunately (for us :)) he is on his honey moon now, so we should probably just try to get the patch into the Ximian packages for now. -- Ettore ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] ORBit performance tweak
Starting with Solaris 9, /dev/random and /dev/urandom will be available. Many sites may also have installed ANDIrand on older releases of Solaris. ANDIrand provides /dev/*random that is compatible with the Linux implementation. Perhaps it would be worthwhile to try out /dev/urandom on Solaris, then use the slow code if reading from /dev/urandom fails. I would suggest a non-blocking read in case someone has mistakenly put a blocking entropy (such as the one with SUNWski) daemon on /dev/urandom. ANDIrand is available from http://www.cosy.sbg.ac.at/~andi/. It is dual-licensed, with one of the licenses being the GPL. Mike On Mon, 2002-04-22 at 11:28, Ettore Perazzoli wrote: On Mon, 2002-04-22 at 01:22, Not Zed wrote: Yeah i did something similar when purifying and quantifying on the Solaris box - I thought 20% of total cpu for initialising 64 objects was a bit much, I guess the timing/scheduling is different enough on solaris to make the algorithm really not work well. I think on Linux we just use /dev/random, that's why you don't need the patch. I wonder who this should go to ... Michael Meeks, who now maintains ORBit. Unfortunately (for us :)) he is on his honey moon now, so we should probably just try to get the patch into the Ximian packages for now. -- Ettore ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers -- Mike Gerdts (919) 850-5284 Unix Systems Administrator [EMAIL PROTECTED] ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
[Evolution-hackers] ORBit performance tweak
So, when remotely displaying from my sparc to a machine on the same lan
it takes 48 seconds to bring up the first window. This change to
genrand.c (rolling orbit2's genuid_simple in, and using that when
buf_len is 8 or more) drops it down to 18 seconds.
Displaying locally the time after the patch is 12 seconds from start to
first window, so there's probably still some room for improvement
elsewhere.
Doesn't appear to noticeably change freebsd's startup time (it was ~4-5
seconds before and after the change).
Chris
Index: genrand.c
===
RCS file: /cvs/gnome/ORBit/src/orb/genrand.c,v
retrieving revision 1.2.4.1
diff -u -r1.2.4.1 genrand.c
--- genrand.c 18 Jan 2001 20:16:44 - 1.2.4.1
+++ genrand.c 19 Apr 2002 00:01:05 -
-29,6 +29,44
return TRUE;
}
+static void
+orbit2_xor_buffer (guchar *buffer, int length)
+{
+ static glong s = 0x6b842128;
+ glong i, t;
+ GTimeVal time;
+
+ g_get_current_time (time);
+
+ t = time.tv_sec ^ time.tv_usec;
+
+ for (i = 0; i length; i++)
+ buffer [i] ^= (guchar) (s ^ (t i));
+
+ s ^= t;
+}
+
+static gboolean
+orbit2_genrand_simple(guchar *buffer, int buf_len)
+{
+ static guint32 inc = 0;
+ pid_t pid = getpid();
+
+ if (buf_len 8)
+ return;
+
+ memset (buffer, 0, buf_len);
+
+ inc++;
+
+ memcpy (buffer, inc, 4);
+ memcpy (buffer + 4, pid, 4);
+
+ orbit2_xor_buffer (buffer, buf_len);
+
+ return TRUE;
+}
+
static volatile int received_alarm = 0;
static void
-105,6 +143,8
g_return_if_fail(buf_len);
if(genrand_dev(buffer, buf_len))
+return;
+ else if(orbit2_genrand_simple(buffer, buf_len))
return;
else if(genrand_unix(buffer, buf_len))
return;
