On Fri, Jul 01, 2016 at 03:34:51PM +0200, Bernd Schmidt wrote:
> On 06/21/2016 04:47 PM, Trevor Saunders wrote:
> > On Mon, Jun 20, 2016 at 06:52:35PM +0200, Bernd Schmidt wrote:
>
> > > So that's a second more in real time - was the machine very busy at the
> > > time
> > > you ran these tests s
On 06/21/2016 04:47 PM, Trevor Saunders wrote:
On Mon, Jun 20, 2016 at 06:52:35PM +0200, Bernd Schmidt wrote:
So that's a second more in real time - was the machine very busy at the time
you ran these tests so that these aren't meaningful, or is there a need to
investigate this?
Well, it was
On 06/21/2016 08:47 AM, Trevor Saunders wrote:
On Mon, Jun 20, 2016 at 06:52:35PM +0200, Bernd Schmidt wrote:
On 06/20/2016 12:22 PM, tbsaunde+...@tbsaunde.org wrote:
In theory I would expect if anything this helps performance since it isn't
necessary to malloc every time a node is added, howev
On Mon, Jun 20, 2016 at 06:52:35PM +0200, Bernd Schmidt wrote:
> On 06/20/2016 12:22 PM, tbsaunde+...@tbsaunde.org wrote:
> > In theory I would expect if anything this helps performance since it isn't
> > necessary to malloc every time a node is added, however the data is less
> > clear.
>
> Well
On 06/20/2016 12:22 PM, tbsaunde+...@tbsaunde.org wrote:
In theory I would expect if anything this helps performance since it isn't
necessary to malloc every time a node is added, however the data is less clear.
Well, we have alloc pools for these lists, so a malloc is not needed for
every nod
From: Trevor Saunders
Hi,
These few patches to get rid of rtx insn and expr lists should be pretty un
controvertial. In each case the list is clearly used as a stack and using a
vec as a stack is clearly the same.
In theory I would expect if anything this helps performance since it isn't
neces
