Quick Links

Re: bytea memory improvement

From:	Luis Vilar Flores <lflores(at)evolute(dot)pt>
To:	till toenges <tt(at)kyon(dot)de>, pgsql-jdbc(at)postgresql(dot)org
Subject:	Re: bytea memory improvement
Date:	2006-09-26 15:35:16
Message-ID:	451948B4.1060309@evolute.pt
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Thread:
Lists:	pgsql-jdbc

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Your explanation is very simple and correctly explains both methods. 
 
Here are some more comments ... 
 
till toenges wrote:
<blockquote cite="mid45192600(dot)5050704(at)kyon(dot)de" type="cite">
<pre wrap="">Kris Jurka wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I'm not super impressed with these timing results. They are certainly
showing some effects due to GC, consider the rise in time here at 10.5MB.
</pre>
</blockquote>
<pre wrap="">
The method isn't neccessarily much faster, especially when there are
only a few megabytes involved. This is very difficult to benchmark in
the presence of a garbage collector.

</pre>
<blockquote type="cite">
<pre wrap="">I've committed this to CVS HEAD with a rather arbitrarily set
MAX_3_BUFF_SIZE value of 2MB. Note that this is also the escaped size, so
we may actually be dealing with output data a quarter of that size. If
anyone could do some more testing of what a good crossover point would be
that would be a good thing.
</pre>
</blockquote>
<pre wrap="">
AFAIK the MAX_3_BUFF_SIZE entry was a debug artifact. Not needed any
</pre>
</blockquote>
It's almost correct, I would like the new code to be more tested before
it fully replaces the old - in large arrays there's a big memory
advantage, so it makes sense to replace, in small array it's almost the
same, so the old code can stay for a while ... 
<blockquote cite="mid45192600(dot)5050704(at)kyon(dot)de" type="cite">
<pre wrap="">more. The new method is always faster or at least as fast as the old
method, because it requires fewer memory accesses.

3 Buffers:

Buffer1 zeroing (vm intern)
Buffer1 filling

Buffer2 zeroing (vm intern)
Buffer1 reading
Buffer2 writing

Buffer3 zeroing (vm intern)
Buffer2 reading
Buffer3 writing

Total: 8 memory accesses.

Eventually Buffer3 reading, but that's not part of the driver.

2 Buffers:

Buffer1 zeroing (vm intern)
Buffer1 filling

Buffer1 reading (the new pass)

Buffer2 zeroing (vm intern)
Buffer1 reading
Buffer2 writing

Total: 6 memory accesses.

Conclusion: The new method uses less memory. It must be faster as well,
since everything else is fast in comparison to memory access.

Additionally, it requires only 2 allocations, and memory allocation have
some overhead as well, and mean more work for the garbage collector in
the end. Even if the VM can do some magic to avoid zeroing the buffers,
the newer method has one less memory access. It is always the winner.

</pre>
</blockquote>
Not all memory accesses are created equal :-), the Buffer1 is the
biggest buffer, and the new code pass one more time through it. The
last copy from Buffer3 to Buffer2 in the old method is done through
System.arraycopy, which I think is very, very fast (hardware based), so
the methods are more balanced ... 
For large arrays the new is ALWAYS much faster off course - due to
memory access. 
 
<blockquote cite="mid45192600(dot)5050704(at)kyon(dot)de" type="cite">
<pre wrap="">---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

</pre>
</blockquote>
 
 
<div class="moz-signature">-- 
<meta http-equiv="CONTENT-TYPE" content="text/html; ">
<title>Evolute - Luis Flores</title>
 Luis Flores


 Analista de Sistemas
<a href="http://www.evolute.pt">Evolute - Consultoria
Informática 
 
</a>
 Email: 
<a href="mailto:lflores(at)evolute(dot)pt">lflores(at)evolute(dot)pt
</a>

 Tel: (+351)
212949689
<div style="text-align: justify;">
 
AVISO DE CONFIDENCIALIDADE 

Esta mensagem de correio electrónico e eventuais ficheiros
anexos são confidenciais e destinados apenas à(s)
pessoa(s) ou entidade(s) acima referida(s),
podendo conter informação privilegiada e
confidencial, a qual não poderá ser divulgada,
copiada, gravada ou distribuída nos termos da lei vigente.
Caso não
seja o destinatário da mensagem, ou se ela lhe foi enviada
por engano, agradecemos que não faça uso ou
divulgação da mesma. A
distribuição ou
utilização da informação
nela contida é interdita. Se recebeu esta mensagem por
engano, por favor notifique o remetente e apague este e-mail do seu
sistema.
Obrigado.
 

 

CONFIDENTIALITY NOTICE 

This e-mail transmission and eventual attached files are intended only
for the use of the individual(s) or entity(ies) named above and may
contain
information that is both privileged and confidential and is exempt from
disclosure under applicable law. If you are not the intended recipient,
you are
hereby notified that any disclosure, copying, distribution or use of
any of the information contained in this transmission is strictly
restricted. If by any
means you have received this transmission in error, please immediately
notify the sender and delete this e-mail from your system. Thank you.
</div>
</div>
</body>
</html>

Attachment	Content-Type	Size
unknown_filename	text/html	6.4 KB

In response to

Re: bytea memory improvement at 2006-09-26 13:07:12 from till toenges

Responses

Re: bytea memory improvement - test results at 2006-10-06 19:21:03 from Luis Vilar Flores

Browse pgsql-jdbc by date

	From	Date	Subject
Next Message	Jeanna Geier	2006-09-26 15:43:32	Beginner's Question: No pg_hba.conf entry for host...SSL Off
Previous Message	Markus Schaber	2006-09-26 13:20:03	Re: Bind message