Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dFDrv-0004Hp-5T for pgadmin-hackers@arkaria.postgresql.org; Mon, 29 May 2017 06:09:31 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dFDru-0001eY-Cx for pgadmin-hackers@arkaria.postgresql.org; Mon, 29 May 2017 06:09:30 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dFDre-0001Cw-AH for pgadmin-hackers@postgresql.org; Mon, 29 May 2017 06:09:14 +0000 Received: from mail-wm0-x235.google.com ([2a00:1450:400c:c09::235]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dFDra-0008BT-Bw for pgadmin-hackers@postgresql.org; Mon, 29 May 2017 06:09:12 +0000 Received: by mail-wm0-x235.google.com with SMTP id e127so44603913wmg.1 for ; Sun, 28 May 2017 23:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sCyUoqZlcfLSnTDko0IOCk234sMSrHMxBVPiCSzzTXM=; b=yse+ih4UBEfKmS8+1BNz5gTlS+zyzoXy5i0eS4U2y047z9idsZxcOEqlyq2Y50e06y oGMURGINwT7FJ0RvAcxzhXyQz+aesXcBrny/jeUofRBYa3wQWA61k368/SlnS2bsmrMn mVGfXmTXhKwzXcChBXGMgwCiAIQYsmdZG7IJhfMXWRPpt5dSmTy3u13rT3io9L7v/+++ SlelXf570W7bWeo2MgZP1jy2rCbPXocF4YH9ND+DL1EUDGoHUpE99s6WZ/cMU7xQZLY9 7NETlEIHj42EhRODWJiDhj14caMelY+9ty5pkxvQjLRteuDEmYtOI5bb8U8ew1jnfZ/8 7ptg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sCyUoqZlcfLSnTDko0IOCk234sMSrHMxBVPiCSzzTXM=; b=QUxK1d6KYQtbkC2rJIRH59vjAYspgPhxcLkV61vc+OXglQRUUR6ybDn08DADtv3ayc xRYoxiLpXuGq9NaqM+VwFlu+58Nyg7FKZE07aV4YxSu0HVzn+2hNh1gu5TYNbwuczVxq iZ8RKL04qF4fHVbbpqZhDCJTdoh/PUK/0PdycuyeIfprU723DxuiLGd4B48H2lQ/fzAd 3NUMfyla6H2yz1xyxemybT5S7GOKyRWDihMlZ2ArRKk0xkGusvCPRlXt8x/fIJe0zTlw Nhd2c7hjIov5UWKFpajSomnB+uGc26v6GD+v1vJIu8Vx/RLBR2mhfxRPVN7Y2HAuGLKq 9NUA== X-Gm-Message-State: AODbwcBa/cH/MyrpFqCGg+EHvcm2B+XX2Hd8DGtTQHXjiYpujxg8Wu/U o1SWzTMDEkLF12uDMRhLYMwUuLrOmC9M X-Received: by 10.223.162.218 with SMTP id t26mr9484768wra.107.1496038147708; Sun, 28 May 2017 23:09:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.19.138 with HTTP; Sun, 28 May 2017 23:08:36 -0700 (PDT) In-Reply-To: References: From: Surinder Kumar Date: Mon, 29 May 2017 11:38:36 +0530 Message-ID: Subject: Re: pgAdmin 4 commit: Cleanup handling of default/null values when data edi To: Dave Page Cc: Harshal Dhumal , pgadmin-hackers Content-Type: multipart/mixed; boundary="f403045eb8385dfb9c0550a3867a" X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgadmin-hackers Precedence: bulk Sender: pgadmin-hackers-owner@postgresql.org --f403045eb8385dfb9c0550a3867a Content-Type: multipart/alternative; boundary="f403045eb8385dfb970550a38678" --f403045eb8385dfb970550a38678 Content-Type: text/plain; charset="UTF-8" Hi Dave, The grid was being re-rendered after add new row and copy/paste to add a blank row in the end of grid, but in case of copy/paste batch operation it should run once, so that code is moved out of addNewRow(...) and put into a function grid.addBlankRow() and called separately for copy/paste after batch operation is completed. Now copy/paste with 10k records took 2 seconds. Please find attached patch. On Mon, May 29, 2017 at 5:19 AM, Dave Page wrote: > On Sun, May 28, 2017 at 1:25 PM, Harshal Dhumal > wrote: > > Hi, > > > > This commit has some performance issues with row paste functionality. > > For 2K copied rows with 3 columns (2 integer and one null column) it took > > near about 10 seconds to complete paste operation. And entire application > > becomes unresponsive for those 10 seconds. > > > > This is mainly because for each single pasted row entire grid is > re-rendered > > ( is what I see in code). > > Ideally grid should be re-rendered only once after all rows are provided > to > > grid. > > > > below code snippet from _paste_rows function > > > > _.each(copied_rows, function(row) { > > var new_row = arr_to_object(row); > > new_row.is_row_copied = true; > > row = new_row; > > self.temp_new_rows.push(count); > > grid.onAddNewRow.notify( > > {item: new_row, column: self.columns[0] , grid:grid} > > ) > > grid.setSelectedRows([]); > > count++; > > }); > > > > The statement > > > > grid.onAddNewRow.notify( > > {item: new_row, column: self.columns[0] , grid:grid} > > ) > > > > causes grid to re-render (as we listener on onAddNewRow event where we > > re-render the grid) > > Copying that number of rows is an extreme case of course, but still... > Is there an alternative way to batch notify? > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > --f403045eb8385dfb970550a38678 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi = Dave,

The grid was being = re-rendered after add new row and copy/paste to add a blank row in the end = of grid, but in case of copy/paste batch operation it should run once, so t= hat code is moved out of = addNewRow(...) and put into a function grid.addBlankRow() and called separately for co= py/paste after batch operation is completed.

Now copy/paste with 10k records took 2 seconds.
<= div class=3D"gmail_default" style=3D"font-size:small">
Please find attached patch.


On Mon, May 29, 2017 at = 5:19 AM, Dave Page <dpage@pgadmin.org> wrote:
On Sun, May 28, 2017 at 1:25 PM, Harshal Dhumal<= br> <ha= rshal.dhumal@enterprisedb.com> wrote:
> Hi,
>
> This commit has some performance issues with row paste functionality.<= br> > For 2K copied rows with 3 columns (2 integer and one null column) it t= ook
> near about 10 seconds to complete paste operation. And entire applicat= ion
> becomes unresponsive for those 10 seconds.
>
> This is mainly because for each single pasted row entire grid is re-re= ndered
> ( is what I see in code).
> Ideally grid should be re-rendered only once after all rows are provid= ed to
> grid.
>
> below code snippet from _paste_rows function
>
> _.each(copied_rows, function(row) {
>=C2=A0 =C2=A0 =C2=A0var new_row =3D arr_to_object(row);
>=C2=A0 =C2=A0 =C2=A0new_row.is_row_copied =3D true;
>=C2=A0 =C2=A0 =C2=A0row =3D new_row;
>=C2=A0 =C2=A0 =C2=A0self.temp_new_rows.push(count);
>=C2=A0 =C2=A0 =C2=A0grid.onAddNewRow.notify(
>=C2=A0 =C2=A0 =C2=A0 =C2=A0{item: new_row, column: self.columns[0] , gr= id:grid}
>=C2=A0 =C2=A0 =C2=A0)
>=C2=A0 =C2=A0 =C2=A0grid.setSelectedRows([]);
>=C2=A0 =C2=A0 =C2=A0count++;
> });
>
> The statement
>
> grid.onAddNewRow.notify(
>=C2=A0 =C2=A0 =C2=A0 =C2=A0{item: new_row, column: self.columns[0] , gr= id:grid}
>=C2=A0 =C2=A0 =C2=A0)
>
> causes grid to re-render (as we listener on onAddNewRow event where we=
> re-render the grid)

Copying that number of rows is an extreme case of course, but s= till...
Is there an alternative way to batch notify?
=
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--f403045eb8385dfb970550a38678-- --f403045eb8385dfb9c0550a3867a Content-Type: application/octet-stream; name="render_grid_after_batch_copy_paste_rows.patch" Content-Disposition: attachment; filename="render_grid_after_batch_copy_paste_rows.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j39qgohb0 ZGlmZiAtLWdpdCBhL3dlYi9wZ2FkbWluL3Rvb2xzL3NxbGVkaXRvci90ZW1w bGF0ZXMvc3FsZWRpdG9yL2pzL3NxbGVkaXRvci5qcyBiL3dlYi9wZ2FkbWlu L3Rvb2xzL3NxbGVkaXRvci90ZW1wbGF0ZXMvc3FsZWRpdG9yL2pzL3NxbGVk aXRvci5qcwppbmRleCA3ZDUxMTkzLi41OTdjNDM2IDEwMDY0NAotLS0gYS93 ZWIvcGdhZG1pbi90b29scy9zcWxlZGl0b3IvdGVtcGxhdGVzL3NxbGVkaXRv ci9qcy9zcWxlZGl0b3IuanMKKysrIGIvd2ViL3BnYWRtaW4vdG9vbHMvc3Fs ZWRpdG9yL3RlbXBsYXRlcy9zcWxlZGl0b3IvanMvc3FsZWRpdG9yLmpzCkBA IC05MTAsNiArOTEwLDE0IEBAIGRlZmluZSgKICAgICAgICAgICAkKCIjYnRu LXNhdmUiKS5wcm9wKCdkaXNhYmxlZCcsIGZhbHNlKTsKICAgICAgICAgfS5i aW5kKGVkaXRvcl9kYXRhKSk7CiAKKyAgICAgICAgZ3JpZC5hZGRCbGFua1Jv dyA9IGZ1bmN0aW9uKCkgeworICAgICAgICAgIC8vIEFkZCBhIGJsYW5rIHJv dyBpbiB0aGUgZW5kIG9mIGdyaWQKKyAgICAgICAgICB0aGlzLnNldERhdGEo dGhpcy5nZXREYXRhKCksIHRydWUpOworICAgICAgICAgIHRoaXMudXBkYXRl Um93Q291bnQoKTsKKyAgICAgICAgICB0aGlzLmludmFsaWRhdGVBbGxSb3dz KCk7CisgICAgICAgICAgdGhpcy5yZW5kZXIoKTsKKyAgICAgICAgfTsKKwog ICAgICAgICAvLyBMaXN0ZW5lciBmdW5jdGlvbiB3aGljaCB3aWxsIGJlIGNh bGxlZCB3aGVuIHVzZXIgYWRkcyBuZXcgcm93cwogICAgICAgICBncmlkLm9u QWRkTmV3Um93LnN1YnNjcmliZShmdW5jdGlvbiAoZSwgYXJncykgewogICAg ICAgICAgIC8vIHNlbGYuaGFuZGxlci5kYXRhX3N0b3JlLmFkZGVkIHdpbGwg aG9sZHMgYWxsIHRoZSBuZXdseSBhZGRlZCByb3dzL2RhdGEKQEAgLTk0MSwx MCArOTQ5LDkgQEAgZGVmaW5lKAogICAgICAgICAgIGdyaWQucmVuZGVyKCk7 CiAKICAgICAgICAgICAvLyBBZGQgYSBibGFuayByb3cgYWZ0ZXIgYWRkIHJv dwotICAgICAgICAgIGdyaWQuc2V0RGF0YShuZXdfY29sbGVjdGlvbiwgdHJ1 ZSk7Ci0gICAgICAgICAgZ3JpZC51cGRhdGVSb3dDb3VudCgpOwotICAgICAg ICAgIGdyaWQuaW52YWxpZGF0ZUFsbFJvd3MoKTsKLSAgICAgICAgICBncmlk LnJlbmRlcigpOworICAgICAgICAgIGlmICghYXJncy5pc19jb3B5X3Jvdykg eworICAgICAgICAgICAgZ3JpZC5hZGRCbGFua1JvdygpOworICAgICAgICAg IH0KIAogICAgICAgICAgIC8vIEVuYWJsZSBzYXZlIGJ1dHRvbgogICAgICAg ICAgICQoIiNidG4tc2F2ZSIpLnByb3AoJ2Rpc2FibGVkJywgZmFsc2UpOwpA QCAtMzE3MSwxMSArMzE3OCwxNyBAQCBkZWZpbmUoCiAgICAgICAgICAgICAg ICAgICByb3cgPSBuZXdfcm93OwogICAgICAgICAgICAgICAgICAgc2VsZi50 ZW1wX25ld19yb3dzLnB1c2goY291bnQpOwogICAgICAgICAgICAgICAgICAg Z3JpZC5vbkFkZE5ld1Jvdy5ub3RpZnkoCi0gICAgICAgICAgICAgICAgICAg IHtpdGVtOiBuZXdfcm93LCBjb2x1bW46IHNlbGYuY29sdW1uc1swXSAsIGdy aWQ6Z3JpZH0KKyAgICAgICAgICAgICAgICAgICAgeyBpdGVtOiBuZXdfcm93 LAorICAgICAgICAgICAgICAgICAgICAgIGNvbHVtbjogc2VsZi5jb2x1bW5z WzBdLAorICAgICAgICAgICAgICAgICAgICAgIGdyaWQ6IGdyaWQsCisgICAg ICAgICAgICAgICAgICAgICAgaXNfY29weV9yb3c6IHRydWUKKyAgICAgICAg ICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgKQotICAgICAgICAg ICAgICAgICAgZ3JpZC5zZXRTZWxlY3RlZFJvd3MoW10pOwogICAgICAgICAg ICAgICAgICAgY291bnQrKzsKICAgICAgICAgICAgICAgfSk7CisgICAgICAg ICAgICAgIC8vIEFkZCBhIGJsYW5rIHJvdyBhZnRlciBjb3B5L3Bhc3RlIHJv dworICAgICAgICAgICAgICBncmlkLmFkZEJsYW5rUm93KCk7CisgICAgICAg ICAgICAgIGdyaWQuc2V0U2VsZWN0ZWRSb3dzKFtdKTsKICAgICAgICAgICAg IH0KICAgICAgICAgfSwKIAo= --f403045eb8385dfb9c0550a3867a Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers --f403045eb8385dfb9c0550a3867a--