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 051C2200D01 for ; Fri, 22 Sep 2017 16:06:11 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 01CB51609BE; Fri, 22 Sep 2017 14:06:11 +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 3D3A91609A7 for ; Fri, 22 Sep 2017 16:06:10 +0200 (CEST) Received: (qmail 85268 invoked by uid 500); 22 Sep 2017 14:06:09 -0000 Mailing-List: contact reviews-help@spark.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list reviews@spark.apache.org Received: (qmail 85257 invoked by uid 99); 22 Sep 2017 14:06:09 -0000 Received: from git1-us-west.apache.org (HELO git1-us-west.apache.org) (140.211.11.23) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Sep 2017 14:06:09 +0000 Received: by git1-us-west.apache.org (ASF Mail Server at git1-us-west.apache.org, from userid 33) id 135AEF5615; Fri, 22 Sep 2017 14:06:09 +0000 (UTC) From: hvanhovell To: reviews@spark.apache.org Reply-To: reviews@spark.apache.org References: In-Reply-To: Subject: [GitHub] spark issue #19222: [SPARK-10399][CORE][SQL] Introduce multiple MemoryBlocks... Content-Type: text/plain Message-Id: <20170922140609.135AEF5615@git1-us-west.apache.org> Date: Fri, 22 Sep 2017 14:06:09 +0000 (UTC) archived-at: Fri, 22 Sep 2017 14:06:11 -0000 Github user hvanhovell commented on the issue: https://github.com/apache/spark/pull/19222 Circling back to the inheritance discussion. My worry is that this will introduce a lot polymorphic call sites in very performance critical code. Even if you tag on final to each method, the call site will still be monomorphic. There are two options from my end: 1. Convince me wrong, by posting benchmark before and after benchmark results. 2. Use a single class that combines the various implementations. This is very easy to do and will have relatively little overhead. Also cc @rednaxelafx In all I really think this work is worth the effort. It should make working with Spark internals a lot easier/safer. --- --------------------------------------------------------------------- To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org For additional commands, e-mail: reviews-help@spark.apache.org