Hi,

Attached are two small patches which eliminate some tight malloc/free
cycles while servicing common XRender requests.  This goes in
conjunction with overhead-reduction and fastpath patches already
submitted to Pixman.

Since even good malloc implementations have significant overhead, this
improves throughput for small requests in particular.  We've seen about
20% on ARMv7-A hardware, over and above the improvement from running an
optimised Pixman library.

Note that the simple object-pools implemented here are not thread-safe.
As I understand it, thread-safety is not a requirement for X.org.
Please do correct me if necessary.

A further, rather heavier patch is necessary to eliminate all
malloc/free cycles from RenderGlyphs calls, which results in
considerable further improvements in glyph-request throughput.  I'll
post that when I'm happier with it, since it involves major surgery to
miGlyphs().

-- 
------
From: Jonathan Morton
      [email protected]

>From 9a34e056a1018014927a316307b1cf543da68357 Mon Sep 17 00:00:00 2001
From: Jonathan Morton <[email protected]>
Date: Mon, 8 Jun 2009 12:17:24 +0300
Subject: [PATCH] Introduce region-object pool to avoid malloc/free overhead.

---
 mi/miregion.c |   22 ++++++++++++++++++----
 1 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/mi/miregion.c b/mi/miregion.c
index c48befc..a352cc6 100644
--- a/mi/miregion.c
+++ b/mi/miregion.c
@@ -224,6 +224,11 @@ RegDataRec miEmptyData = {0, 0};
 RegDataRec  miBrokenData = {0, 0};
 static RegionRec   miBrokenRegion = { { 0, 0, 0, 0 }, &miBrokenData };
 
+/* Avoid calling malloc every time one of these is needed */
+#define REGION_POOL_SIZE (4)
+static RegionPtr miRegionPool[REGION_POOL_SIZE] = {NULL};
+static uint32_t miRegionPoolTop = 0;
+
 void
 InitRegions (void)
 {
@@ -239,9 +244,13 @@ InitRegions (void)
 RegionPtr
 miRegionCreate(BoxPtr rect, int size)
 {
-    RegionPtr pReg;
+    RegionPtr pReg = NULL;
    
-    pReg = (RegionPtr)xalloc(sizeof(RegionRec));
+    if(miRegionPoolTop)
+        pReg = miRegionPool[--miRegionPoolTop];
+    else
+        pReg = (RegionPtr)xalloc(sizeof(RegionRec));
+
     if (!pReg)
 	return &miBrokenRegion;
 
@@ -254,8 +263,13 @@ void
 miRegionDestroy(RegionPtr pReg)
 {
     pixman_region_fini (pReg);
-    if (pReg != &miBrokenRegion)
-	xfree(pReg);
+
+    if (pReg != &miBrokenRegion) {
+        if(miRegionPoolTop < REGION_POOL_SIZE)
+            miRegionPool[miRegionPoolTop++] = pReg;
+        else
+	    xfree(pReg);
+    }
 }
 
 void
-- 
1.5.6.3

>From ff0224fe256ebc0726ffda27e4a93dc09f4e3bb2 Mon Sep 17 00:00:00 2001
From: Jonathan Morton <[email protected]>
Date: Mon, 8 Jun 2009 12:18:02 +0300
Subject: [PATCH] Introduce picture-object pool to avoid malloc/free overhead.

---
 render/picture.c |   17 +++++++++++++++--
 1 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/render/picture.c b/render/picture.c
index 5f86c7c..c94add0 100644
--- a/render/picture.c
+++ b/render/picture.c
@@ -703,6 +703,11 @@ SetPictureToDefaults (PicturePtr    pPicture)
     pPicture->pSourcePict = 0;
 }
 
+/* Avoid calling malloc every time one of these is needed */
+#define PICTURE_POOL_SIZE (4)
+static PicturePtr PicturePool[PICTURE_POOL_SIZE] = {NULL};
+static uint32_t PicturePoolTop = 0;
+
 PicturePtr
 CreatePicture (Picture		pid,
 	       DrawablePtr	pDrawable,
@@ -715,7 +720,11 @@ CreatePicture (Picture		pid,
     PicturePtr		pPicture;
     PictureScreenPtr	ps = GetPictureScreen(pDrawable->pScreen);
 
-    pPicture = (PicturePtr)xalloc(sizeof(PictureRec));
+    if(PicturePoolTop)
+        pPicture = PicturePool[--PicturePoolTop];
+    else
+        pPicture = (PicturePtr)xalloc(sizeof(PictureRec));
+
     if (!pPicture)
     {
 	*error = BadAlloc;
@@ -1531,7 +1540,11 @@ FreePicture (pointer	value,
             }
         }
 	dixFreePrivates(pPicture->devPrivates);
-	xfree (pPicture);
+
+        if(PicturePoolTop < PICTURE_POOL_SIZE)
+            PicturePool[PicturePoolTop++] = pPicture;
+        else
+	    xfree (pPicture);
     }
     return Success;
 }
-- 
1.5.6.3

_______________________________________________
xorg-devel mailing list
[email protected]
http://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to