<div dir="ltr"><div style>All is true. But average UUID.fromString execution is 1675us, and HashMap.put is 78us - so the benefit is clear when we&#39;re talking on &gt;100K executions for 10minutes...</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sun, Jun 30, 2013 at 12:44 PM, Michael Pasternak <span dir="ltr">&lt;<a href="mailto:mpastern@redhat.com" target="_blank">mpastern@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 06/30/2013 12:20 PM, Liran Zelkha wrote:<br>
&gt; I checked such a solution using JProfiler. Creating the GUID object takes much more CPU cycles that checking the string in the Map.<br>
<br>
</div>of course it is, but what is the size of map that you checked?, check on worst scenario, i.e map<br>
is full of all possible guids,<br>
<br>
also problem a bit different,java map has a load factor (which is usually 0.75),<br>
when ratio increases beyond the load factor, occurs proses called re-hash so that the hash<br>
table will double amount of buckets. what can produce a cpu spikes (though it should not happen too often),<br>
to avoid this the initial capacity should be greater than the maximum number of entries / the<br>
load factor, and this is a huge map....<br>
<br>
so basically this is a tradeoff between time and space costs against the new guid generation.<br>
<div class="HOEnZb"><div class="h5"><br>
&gt;<br>
&gt; On Jun 30, 2013, at 12:06 PM, Michael Pasternak wrote:<br>
&gt;<br>
&gt;&gt; On 06/30/2013 11:37 AM, Liran Zelkha wrote:<br>
&gt;&gt;&gt; Great news.<br>
&gt;&gt;&gt; Allon - please note that GUID is being recreated from String by both DB calls and by data received from VDSM. It is VERY useful to cache Guid String--&gt;Guid, and not just Empty GUID.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; However, as the Guid class runs in GWT as well, you can&#39;t use Infinispan and you&#39;re limited in the HashMap implementations you can use.<br>
&gt;&gt;&gt; Personally, I don&#39;t think it&#39;s a memory leak, as GUID number in the system are finite and not too large.<br>
&gt;&gt;<br>
&gt;&gt; it&#39;s large, it&#39;s 128-bit random number, it&#39;s not about memory leaking, but cpu cost,<br>
&gt;&gt; as you&#39;ll face a lot of rehash&#39;ings in the map,<br>
&gt;&gt;<br>
&gt;&gt; i&#39;m not even sure that using indexing in the map can help, worth checking.<br>
&gt;&gt;<br>
&gt;&gt; What do you think? Want to add it to your patch?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Jun 30, 2013, at 11:13 AM, Yair Zaslavsky wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Well done, should have been done ages ago :)<br>
&gt;&gt;&gt;&gt; Now, for the painful rebase of async_task_mgr changes :)<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; ----- Original Message -----<br>
&gt;&gt;&gt;&gt;&gt; From: &quot;Allon Mureinik&quot; &lt;<a href="mailto:amureini@redhat.com">amureini@redhat.com</a>&gt;<br>
&gt;&gt;&gt;&gt;&gt; To: &quot;engine-devel&quot; &lt;<a href="mailto:engine-devel@ovirt.org">engine-devel@ovirt.org</a>&gt;, &quot;Barak Azulay&quot; &lt;<a href="mailto:bazulay@redhat.com">bazulay@redhat.com</a>&gt;<br>

&gt;&gt;&gt;&gt;&gt; Cc: &quot;Yair Zaslavsky&quot; &lt;<a href="mailto:yzaslavs@redhat.com">yzaslavs@redhat.com</a>&gt;, &quot;Michael Pasternak&quot; &lt;<a href="mailto:mpastern@redhat.com">mpastern@redhat.com</a>&gt;, &quot;Tal Nisan&quot;<br>

&gt;&gt;&gt;&gt;&gt; &lt;<a href="mailto:tnisan@redhat.com">tnisan@redhat.com</a>&gt;, &quot;Ayal Baron&quot; &lt;<a href="mailto:abaron@redhat.com">abaron@redhat.com</a>&gt;<br>
&gt;&gt;&gt;&gt;&gt; Sent: Sunday, June 30, 2013 11:11:30 AM<br>
&gt;&gt;&gt;&gt;&gt; Subject: Guid improvements<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Hi all,<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; I just merged a couple of improvements to the [N]Guid class [1] to improve<br>
&gt;&gt;&gt;&gt;&gt; it&#39;s performance both CPU-wise and memory-wise, based on a set of benchmarks<br>
&gt;&gt;&gt;&gt;&gt; presented by Liran.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; What this patchset achieves:<br>
&gt;&gt;&gt;&gt;&gt; 1. Clean up the code, so it&#39;s easier to understand and use<br>
&gt;&gt;&gt;&gt;&gt; 2. Eliminate the inflation in the memory foot print caused by the getValue()<br>
&gt;&gt;&gt;&gt;&gt; method<br>
&gt;&gt;&gt;&gt;&gt; 3. Eliminate all the heavy calls to UUID.fromString when creating a new/empty<br>
&gt;&gt;&gt;&gt;&gt; Guid instance as a default value<br>
&gt;&gt;&gt;&gt;&gt; 4. Note that the cleanups proposed in (1) will have minor performance<br>
&gt;&gt;&gt;&gt;&gt; benefits (e.g., eliminating useless conditional statements), but I doubt<br>
&gt;&gt;&gt;&gt;&gt; this would be anything to write home about.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; From a developer&#39;s perspective, here&#39;s what changed:<br>
&gt;&gt;&gt;&gt;&gt; 1. No more NGuid, just Guid. Both static methods to create a Guid from String<br>
&gt;&gt;&gt;&gt;&gt; still exist, and are named createGuidFromString and<br>
&gt;&gt;&gt;&gt;&gt; createGuidFromStringDefaultEmpty.<br>
&gt;&gt;&gt;&gt;&gt; 2. [N]Guid.getValue() was removed, it&#39;s no longer needed after (1) was<br>
&gt;&gt;&gt;&gt;&gt; implemented<br>
&gt;&gt;&gt;&gt;&gt; 3. The Guid() constructor was made private, as it forced a redundant call to<br>
&gt;&gt;&gt;&gt;&gt; UUID.fromString(String). If you need an empty Guid instance, just use<br>
&gt;&gt;&gt;&gt;&gt; Guid.Empty<br>
&gt;&gt;&gt;&gt;&gt; 4. The Guid.EMPTY_GUID_VALUE string constant was removed, as it was used for<br>
&gt;&gt;&gt;&gt;&gt; redundant calls to UUID.fromString. If you really, REALLY, need it, just<br>
&gt;&gt;&gt;&gt;&gt; call Guid.Empty.getValue() for a UUID or Guid.Empty.toString() for a String.<br>
&gt;&gt;&gt;&gt;&gt; 5. All sorts of ways to transform Strings to Guids were removed. If you have<br>
&gt;&gt;&gt;&gt;&gt; a literal you trust, just use new Guid(String). If you suspect it may be<br>
&gt;&gt;&gt;&gt;&gt; null, use Guid.createGuidFromString[DefaultEmpty]<br>
&gt;&gt;&gt;&gt;&gt; 6. NewGuid is now called newGuid. We&#39;re in Java, not C# :-)<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Many thanks to everyone who reviewed this patchset.<br>
&gt;&gt;&gt;&gt;&gt; You guys rock!<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Regards,<br>
&gt;&gt;&gt;&gt;&gt; Allon<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; [1]<br>
&gt;&gt;&gt;&gt;&gt; <a href="http://gerrit.ovirt.org/#/q/project:ovirt-engine+branch:master+topic:guid-cleanup,n,z" target="_blank">http://gerrit.ovirt.org/#/q/project:ovirt-engine+branch:master+topic:guid-cleanup,n,z</a><br>

&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt; Engine-devel mailing list<br>
&gt;&gt;&gt;&gt; <a href="mailto:Engine-devel@ovirt.org">Engine-devel@ovirt.org</a><br>
&gt;&gt;&gt;&gt; <a href="http://lists.ovirt.org/mailman/listinfo/engine-devel" target="_blank">http://lists.ovirt.org/mailman/listinfo/engine-devel</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; Engine-devel mailing list<br>
&gt;&gt;&gt; <a href="mailto:Engine-devel@ovirt.org">Engine-devel@ovirt.org</a><br>
&gt;&gt;&gt; <a href="http://lists.ovirt.org/mailman/listinfo/engine-devel" target="_blank">http://lists.ovirt.org/mailman/listinfo/engine-devel</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt;<br>
&gt;&gt; Michael Pasternak<br>
&gt;&gt; RedHat, ENG-Virtualization R&amp;D<br>
&gt;<br>
<br>
<br>
--<br>
<br>
Michael Pasternak<br>
RedHat, ENG-Virtualization R&amp;D<br>
</div></div></blockquote></div><br></div>