From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49894 invoked by alias); 24 Feb 2016 23:01:26 -0000 Mailing-List: contact libabigail-help@sourceware.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: libabigail-owner@sourceware.org Received: (qmail 49790 invoked by uid 55); 24 Feb 2016 23:01:22 -0000 From: "dodji at seketeli dot org" To: libabigail@sourceware.org Subject: [Bug default/19427] Intern the strings used in Libabigail Date: Fri, 01 Jan 2016 00:00:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: libabigail X-Bugzilla-Component: default X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: dodji at seketeli dot org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: dodji at redhat dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2016-q1/txt/msg00150.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D19427 --- Comment #4 from dodji at seketeli dot org --- > Not that this is any of my business :-) It is, otherwise, this would not be an open project ;-) > The 2% speed difference is insignificant. No-one will care. > > The memory savings are nice, but not *that* huge (around 7%). I'd be incl= ined > to make this kind of change only if the impact on code complexity and > maintainability is low. Actually, someone brought to my attention a test case where we have 30% speed increase ;-) This is on the nss package, from mozilla. That is why I merged it in. In other words, it makes the library scale a lot more on packages with deep aggregate type hierarchies where each aggregate type has a lot of data members, and where sub-types reference each other. If you also have a lot of incomplete types in the mix, then you end up doing a *lot* of type name comparisons. And this is where interned strings help. > I've worked with code bases that create their own string implementation i= n the > past and, usually, it creates more problems than it solves. Often, the pr= oblem > ends up being that the replacement cannot be easily exchanged with std::s= tring > and vice-versa, and then ends up costing more than it saves. So, whenever= I see > a string replacement class, I tend to look twice. Right, I totally agree. This is why I tried very hard to make abigail::interned_string to be just a pointer to std::string, in essence. It's not a new string. The idea is just that comparing two instances or interned_string amounts to comparing the values of the pointers to std::string, as there is only one copy of each distinct std::string in the entire environment now. > I don't know whether you can use boost in your code. As this thing should work on systems that are not updated that much, for instance, el6, we don't use boost, no. --=20 You are receiving this mail because: You are on the CC list for the bug.