Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id CAA6E200BEC for ; Thu, 29 Dec 2016 18:49:46 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id C9474160B2D; Thu, 29 Dec 2016 17:49:46 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 16413160B23 for ; Thu, 29 Dec 2016 18:49:45 +0100 (CET) Received: (qmail 70069 invoked by uid 500); 29 Dec 2016 17:49:45 -0000 Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ignite.apache.org Delivered-To: mailing list dev@ignite.apache.org Received: (qmail 70058 invoked by uid 99); 29 Dec 2016 17:49:45 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Dec 2016 17:49:45 +0000 Received: from [192.168.75.153] (c-73-222-138-29.hsd1.ca.comcast.net [73.222.138.29]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id DBA971A00A8 for ; Thu, 29 Dec 2016 17:49:44 +0000 (UTC) From: Denis Magda Content-Type: multipart/alternative; boundary="Apple-Mail=_7C83E58A-F3AA-44E0-AD9A-0B4C2968EE7E" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: PageMemory approach for Ignite 2.0 Date: Thu, 29 Dec 2016 09:49:43 -0800 References: To: dev@ignite.apache.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3259) archived-at: Thu, 29 Dec 2016 17:49:47 -0000 --Apple-Mail=_7C83E58A-F3AA-44E0-AD9A-0B4C2968EE7E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Alex, > On Dec 29, 2016, at 1:37 AM, Alexey Goncharuk = wrote: >=20 > The subject of this discussion is to determine whether the PageMemory > approach is a way to go, because the this implementation is almost 2x > slower than current 2.0 branch.=20 What is the main reason for that? Some architecture flaw you didn=E2=80=99= t consider before or performance issues that have to be cleaned up? =E2=80=94 Denis= --Apple-Mail=_7C83E58A-F3AA-44E0-AD9A-0B4C2968EE7E--