Why is searching for a value in an object by key slower than using 'for in' in js?How to efficiently count...

How can I block email signup overlays or javascript popups in Safari?

Freedom of speech and where it applies

Can disgust be a key component of horror?

Explaining alternative travel routes when going to the USA

How does the math work for Perception checks?

Aragorn's "guise" in the Orthanc Stone

Count the occurrence of each unique word in the file

Why can Carol Danvers change her suit colours in the first place?

How does a computer interpret real numbers?

Is Witten's Proof of the Positive Mass Theorem Rigorous?

Creepy dinosaur pc game identification

Can I sign legal documents with a smiley face?

Did arcade monitors have same pixel aspect ratio as TV sets?

If a character has darkvision, can they see through an area of nonmagical darkness filled with lightly obscuring gas?

Temporarily disable WLAN internet access for children, but allow it for adults

Yosemite Fire Rings - What to Expect?

A social experiment. What is the worst that can happen?

Lowest total scrabble score

New brakes for 90s road bike

What is going on with 'gets(stdin)' on the site coderbyte?

What changes for testers when they are testing in agile environments?

Added a new user on Ubuntu, set password not working?

Has any country ever had 2 former presidents in jail simultaneously?

How to create ADT in Haskell?



Why is searching for a value in an object by key slower than using 'for in' in js?


How to efficiently count the number of keys/properties of an object in JavaScript?How to determine equality for two JavaScript objects?Checking if a key exists in a JavaScript object?Sort array of objects by string property valueHow can I add a key/value pair to a JavaScript object?Optimum way to compare strings in JavaScript?How do I remove a key from a JavaScript object?Check if a value is an object in JavaScriptWhy is bind slower than a closure?Why is <= slower than < using this code snippet in V8?













25















Why is it slower to search for a value in an object by key than using for in in JavaScript?



Like this code:






const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };

console.time('1');
let n = a['e'].txt;
console.log(n, '<<n')
console.timeEnd('1');

console.time('2');
for (const key in a) {
if (a[key].txt == 5) {
const m = a[key];
console.log(m, '<<m')
break;
}
}
console.timeEnd('2');





The result is




5 '<<by key'
1: 2.329ms
{ txt: 5 } '<<for in '
2: 0.447ms


Isn't this weird?










share|improve this question

























  • Doing accurate timing tests in JavaScript can be tricky. You probably want to do bigger runs to make sure there's actually a real difference.

    – Steve Bennett
    Mar 14 at 7:49






  • 8





    The benchmarking method is flawed.

    – Salman A
    Mar 14 at 9:01
















25















Why is it slower to search for a value in an object by key than using for in in JavaScript?



Like this code:






const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };

console.time('1');
let n = a['e'].txt;
console.log(n, '<<n')
console.timeEnd('1');

console.time('2');
for (const key in a) {
if (a[key].txt == 5) {
const m = a[key];
console.log(m, '<<m')
break;
}
}
console.timeEnd('2');





The result is




5 '<<by key'
1: 2.329ms
{ txt: 5 } '<<for in '
2: 0.447ms


Isn't this weird?










share|improve this question

























  • Doing accurate timing tests in JavaScript can be tricky. You probably want to do bigger runs to make sure there's actually a real difference.

    – Steve Bennett
    Mar 14 at 7:49






  • 8





    The benchmarking method is flawed.

    – Salman A
    Mar 14 at 9:01














25












25








25


3






Why is it slower to search for a value in an object by key than using for in in JavaScript?



Like this code:






const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };

console.time('1');
let n = a['e'].txt;
console.log(n, '<<n')
console.timeEnd('1');

console.time('2');
for (const key in a) {
if (a[key].txt == 5) {
const m = a[key];
console.log(m, '<<m')
break;
}
}
console.timeEnd('2');





The result is




5 '<<by key'
1: 2.329ms
{ txt: 5 } '<<for in '
2: 0.447ms


Isn't this weird?










share|improve this question
















Why is it slower to search for a value in an object by key than using for in in JavaScript?



Like this code:






const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };

console.time('1');
let n = a['e'].txt;
console.log(n, '<<n')
console.timeEnd('1');

console.time('2');
for (const key in a) {
if (a[key].txt == 5) {
const m = a[key];
console.log(m, '<<m')
break;
}
}
console.timeEnd('2');





The result is




5 '<<by key'
1: 2.329ms
{ txt: 5 } '<<for in '
2: 0.447ms


Isn't this weird?






const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };

console.time('1');
let n = a['e'].txt;
console.log(n, '<<n')
console.timeEnd('1');

console.time('2');
for (const key in a) {
if (a[key].txt == 5) {
const m = a[key];
console.log(m, '<<m')
break;
}
}
console.timeEnd('2');





const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };

console.time('1');
let n = a['e'].txt;
console.log(n, '<<n')
console.timeEnd('1');

console.time('2');
for (const key in a) {
if (a[key].txt == 5) {
const m = a[key];
console.log(m, '<<m')
break;
}
}
console.timeEnd('2');






javascript node.js






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 14 at 10:47









dandan78

10.1k95471




10.1k95471










asked Mar 14 at 7:45









Johanna FengJohanna Feng

15017




15017













  • Doing accurate timing tests in JavaScript can be tricky. You probably want to do bigger runs to make sure there's actually a real difference.

    – Steve Bennett
    Mar 14 at 7:49






  • 8





    The benchmarking method is flawed.

    – Salman A
    Mar 14 at 9:01



















  • Doing accurate timing tests in JavaScript can be tricky. You probably want to do bigger runs to make sure there's actually a real difference.

    – Steve Bennett
    Mar 14 at 7:49






  • 8





    The benchmarking method is flawed.

    – Salman A
    Mar 14 at 9:01

















Doing accurate timing tests in JavaScript can be tricky. You probably want to do bigger runs to make sure there's actually a real difference.

– Steve Bennett
Mar 14 at 7:49





Doing accurate timing tests in JavaScript can be tricky. You probably want to do bigger runs to make sure there's actually a real difference.

– Steve Bennett
Mar 14 at 7:49




8




8





The benchmarking method is flawed.

– Salman A
Mar 14 at 9:01





The benchmarking method is flawed.

– Salman A
Mar 14 at 9:01












4 Answers
4






active

oldest

votes


















41














This is because of how the JIT compiler works.



When you start a JS script with Node, the V8 starts interpreting it, while compiling it into native machine code.



Running it in the Chrome Devtools console, I get this output :



5 "<<n"
0.167724609375ms
{txt: 5} "<<m"
2: 0.262939453125ms


NodeJS output :



5 '<<n'
1: 18.684ms
{ txt: 5 } '<<m'
2: 3.713ms


But when inverting the 2 variations :



const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };


console.time('2');
for (const key in a) {
if (a[key].txt = 5) {
const m = a[key];
console.log(m, '<<m')
break;
}
}

console.timeEnd('2');
console.time('1');
let n = a['e'].txt;
console.log(n, '<<n')
console.timeEnd('1');


Output :



{ txt: 5 } '<<m'
2: 22.017ms
5 '<<n'
1: 0.245ms


As you can see, the version that is executed first takes much more time than the second.



However, if you average it, you can see that executing the key access is much faster than the for in loop.






share|improve this answer





















  • 1





    And it's really nice to see if you put both variants in separate files and run them.

    – floriangosse
    Mar 14 at 7:51






  • 1





    Are you sure this is a problem with JIT? My guess would have been initialisation of the console.

    – Bergi
    Mar 14 at 13:08






  • 2





    console already exists, it's native code, it doesn't have to be initialized. The V8 compiles your code Just-In-Time, so it's interpreted before the compiling is done, hence the "slow" start

    – Seblor
    Mar 14 at 13:13





















9














You have an error in your program



if (a[key].txt = 5)


You are not checking if the txt property is equal to 5. You are setting the property to 5 which means you are finished after the first execution of the loop regardless.






share|improve this answer
























  • you are right,I think I miss it when I copy ...

    – Johanna Feng
    Mar 14 at 9:52



















2














In JavaScript you can add or remove properties to objects dynamically. HashMaps are most memory efficient and fast data structures to access the properties. But dynamic nature of JavaScript makes it more difficult and slower. To fix this problem Nodejs V8 Engine internally uses JavaScript hidden classes and inline caching. Both the topics are quite vast to explain in this answer. So please find the blog link here and following is the awesome explanation of Nodejs v8 engine performance video.



In one iteration you can not determine the performance of two algorithms in almost 99% cases. So I have just modified your code and iterated it for 11 times (which is also not sufficient) for the demo purpose. And you can see drastic change in the output.



for (let i = 0; i <= 10; i++) {
const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };

console.time('Hash map access');
let n = a['e'].txt;
console.log(n, '<<n')
console.timeEnd('Hash map access');

console.time('For in loop');
for (const key in a) {
if (a[key].txt == 5) {
const m = a[key];
console.log(m, '<<m')
break;
}
}
console.timeEnd('For in loop');
}


Following is the out-put.



5 '<<n'
Hash map access: 8.580ms
{ txt: 5 } '<<m'
For in loop: 4.301ms
5 '<<n'
Hash map access: 0.177ms
{ txt: 5 } '<<m'
For in loop: 0.377ms
5 '<<n'
Hash map access: 0.170ms
{ txt: 5 } '<<m'
For in loop: 0.196ms
5 '<<n'
Hash map access: 0.162ms
{ txt: 5 } '<<m'
For in loop: 0.186ms
5 '<<n'
Hash map access: 0.483ms
{ txt: 5 } '<<m'
For in loop: 0.465ms
5 '<<n'
Hash map access: 0.435ms
{ txt: 5 } '<<m'
For in loop: 0.503ms
5 '<<n'
Hash map access: 0.500ms
{ txt: 5 } '<<m'
For in loop: 0.471ms
5 '<<n'
Hash map access: 0.528ms
{ txt: 5 } '<<m'
For in loop: 0.487ms
5 '<<n'
Hash map access: 0.492ms
{ txt: 5 } '<<m'
For in loop: 0.494ms
5 '<<n'
Hash map access: 1.033ms
{ txt: 5 } '<<m'
For in loop: 0.726ms
5 '<<n'
Hash map access: 0.484ms
{ txt: 5 } '<<m'
For in loop: 0.649ms


If you observe the output there is drastic change in hash-map access, first it was 8.580ms in second time it was 0.177ms. You can find that after first time hash-map is almost faster than "for in loop". (Sometimes it's not as my system is under a lot of pressure while runnig the code :) )



Also I reversed the order, I put "For in Loop" first and then object [hashmap] following is the result.



{ txt: 5 } '<<m'
For in loop: 16.390ms
5 '<<n'
Hash map access: 0.220ms
{ txt: 5 } '<<m'
For in loop: 0.266ms
5 '<<n'
Hash map access: 0.186ms
{ txt: 5 } '<<m'
For in loop: 0.277ms
5 '<<n'
Hash map access: 0.367ms
{ txt: 5 } '<<m'
For in loop: 0.328ms
5 '<<n'
Hash map access: 0.249ms
{ txt: 5 } '<<m'
For in loop: 0.947ms
5 '<<n'
Hash map access: 4.013ms
{ txt: 5 } '<<m'
For in loop: 0.799ms
5 '<<n'
Hash map access: 0.532ms
{ txt: 5 } '<<m'
For in loop: 0.565ms
5 '<<n'
Hash map access: 0.479ms
{ txt: 5 } '<<m'
For in loop: 0.644ms
5 '<<n'
Hash map access: 0.609ms
{ txt: 5 } '<<m'
For in loop: 0.624ms
5 '<<n'
Hash map access: 0.472ms
{ txt: 5 } '<<m'
For in loop: 0.509ms
5 '<<n'
Hash map access: 0.458ms
{ txt: 5 } '<<m'
For in loop: 0.568ms
5 '<<n'
Hash map access: 0.476ms


We can see first for-in loop has taken 16.39ms while the second only 0.266ms. As mentioned in above answer instantiation takes a lot of time, we can easily validate by seeing these numbers.



Conclusion is while writing the code in JavaScript for Nodejs v8 engine, if we don't add/remove properties on objects it will be more fast and efficient. Also code instantiation takes a lot of time while running the first time.






share|improve this answer

































    2














    As you can see here, testing with JS can be really a mess.






    const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };

    let test = function(x) {
    console.log("Test "+x+" times")
    console.time('1');
    for(let i=0;i<x;i++) {
    let n = a['e'].txt;
    }

    console.timeEnd('1');
    console.time('2');

    for(let i=0;i<x;i++) {
    for (const key in a) {
    if (a[key].txt == 5) {
    const m = a[key];
    break;
    }
    }
    }
    console.timeEnd('2');
    }

    test(1)
    test(100)
    test(100000)
    test(100000)
    test(100000)
    test(10000000)








    share|improve this answer























      Your Answer






      StackExchange.ifUsing("editor", function () {
      StackExchange.using("externalEditor", function () {
      StackExchange.using("snippets", function () {
      StackExchange.snippets.init();
      });
      });
      }, "code-snippets");

      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "1"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55157295%2fwhy-is-searching-for-a-value-in-an-object-by-key-slower-than-using-for-in-in-j%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      4 Answers
      4






      active

      oldest

      votes








      4 Answers
      4






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      41














      This is because of how the JIT compiler works.



      When you start a JS script with Node, the V8 starts interpreting it, while compiling it into native machine code.



      Running it in the Chrome Devtools console, I get this output :



      5 "<<n"
      0.167724609375ms
      {txt: 5} "<<m"
      2: 0.262939453125ms


      NodeJS output :



      5 '<<n'
      1: 18.684ms
      { txt: 5 } '<<m'
      2: 3.713ms


      But when inverting the 2 variations :



      const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };


      console.time('2');
      for (const key in a) {
      if (a[key].txt = 5) {
      const m = a[key];
      console.log(m, '<<m')
      break;
      }
      }

      console.timeEnd('2');
      console.time('1');
      let n = a['e'].txt;
      console.log(n, '<<n')
      console.timeEnd('1');


      Output :



      { txt: 5 } '<<m'
      2: 22.017ms
      5 '<<n'
      1: 0.245ms


      As you can see, the version that is executed first takes much more time than the second.



      However, if you average it, you can see that executing the key access is much faster than the for in loop.






      share|improve this answer





















      • 1





        And it's really nice to see if you put both variants in separate files and run them.

        – floriangosse
        Mar 14 at 7:51






      • 1





        Are you sure this is a problem with JIT? My guess would have been initialisation of the console.

        – Bergi
        Mar 14 at 13:08






      • 2





        console already exists, it's native code, it doesn't have to be initialized. The V8 compiles your code Just-In-Time, so it's interpreted before the compiling is done, hence the "slow" start

        – Seblor
        Mar 14 at 13:13


















      41














      This is because of how the JIT compiler works.



      When you start a JS script with Node, the V8 starts interpreting it, while compiling it into native machine code.



      Running it in the Chrome Devtools console, I get this output :



      5 "<<n"
      0.167724609375ms
      {txt: 5} "<<m"
      2: 0.262939453125ms


      NodeJS output :



      5 '<<n'
      1: 18.684ms
      { txt: 5 } '<<m'
      2: 3.713ms


      But when inverting the 2 variations :



      const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };


      console.time('2');
      for (const key in a) {
      if (a[key].txt = 5) {
      const m = a[key];
      console.log(m, '<<m')
      break;
      }
      }

      console.timeEnd('2');
      console.time('1');
      let n = a['e'].txt;
      console.log(n, '<<n')
      console.timeEnd('1');


      Output :



      { txt: 5 } '<<m'
      2: 22.017ms
      5 '<<n'
      1: 0.245ms


      As you can see, the version that is executed first takes much more time than the second.



      However, if you average it, you can see that executing the key access is much faster than the for in loop.






      share|improve this answer





















      • 1





        And it's really nice to see if you put both variants in separate files and run them.

        – floriangosse
        Mar 14 at 7:51






      • 1





        Are you sure this is a problem with JIT? My guess would have been initialisation of the console.

        – Bergi
        Mar 14 at 13:08






      • 2





        console already exists, it's native code, it doesn't have to be initialized. The V8 compiles your code Just-In-Time, so it's interpreted before the compiling is done, hence the "slow" start

        – Seblor
        Mar 14 at 13:13
















      41












      41








      41







      This is because of how the JIT compiler works.



      When you start a JS script with Node, the V8 starts interpreting it, while compiling it into native machine code.



      Running it in the Chrome Devtools console, I get this output :



      5 "<<n"
      0.167724609375ms
      {txt: 5} "<<m"
      2: 0.262939453125ms


      NodeJS output :



      5 '<<n'
      1: 18.684ms
      { txt: 5 } '<<m'
      2: 3.713ms


      But when inverting the 2 variations :



      const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };


      console.time('2');
      for (const key in a) {
      if (a[key].txt = 5) {
      const m = a[key];
      console.log(m, '<<m')
      break;
      }
      }

      console.timeEnd('2');
      console.time('1');
      let n = a['e'].txt;
      console.log(n, '<<n')
      console.timeEnd('1');


      Output :



      { txt: 5 } '<<m'
      2: 22.017ms
      5 '<<n'
      1: 0.245ms


      As you can see, the version that is executed first takes much more time than the second.



      However, if you average it, you can see that executing the key access is much faster than the for in loop.






      share|improve this answer















      This is because of how the JIT compiler works.



      When you start a JS script with Node, the V8 starts interpreting it, while compiling it into native machine code.



      Running it in the Chrome Devtools console, I get this output :



      5 "<<n"
      0.167724609375ms
      {txt: 5} "<<m"
      2: 0.262939453125ms


      NodeJS output :



      5 '<<n'
      1: 18.684ms
      { txt: 5 } '<<m'
      2: 3.713ms


      But when inverting the 2 variations :



      const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };


      console.time('2');
      for (const key in a) {
      if (a[key].txt = 5) {
      const m = a[key];
      console.log(m, '<<m')
      break;
      }
      }

      console.timeEnd('2');
      console.time('1');
      let n = a['e'].txt;
      console.log(n, '<<n')
      console.timeEnd('1');


      Output :



      { txt: 5 } '<<m'
      2: 22.017ms
      5 '<<n'
      1: 0.245ms


      As you can see, the version that is executed first takes much more time than the second.



      However, if you average it, you can see that executing the key access is much faster than the for in loop.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Mar 14 at 7:59

























      answered Mar 14 at 7:50









      SeblorSeblor

      2,9781428




      2,9781428








      • 1





        And it's really nice to see if you put both variants in separate files and run them.

        – floriangosse
        Mar 14 at 7:51






      • 1





        Are you sure this is a problem with JIT? My guess would have been initialisation of the console.

        – Bergi
        Mar 14 at 13:08






      • 2





        console already exists, it's native code, it doesn't have to be initialized. The V8 compiles your code Just-In-Time, so it's interpreted before the compiling is done, hence the "slow" start

        – Seblor
        Mar 14 at 13:13
















      • 1





        And it's really nice to see if you put both variants in separate files and run them.

        – floriangosse
        Mar 14 at 7:51






      • 1





        Are you sure this is a problem with JIT? My guess would have been initialisation of the console.

        – Bergi
        Mar 14 at 13:08






      • 2





        console already exists, it's native code, it doesn't have to be initialized. The V8 compiles your code Just-In-Time, so it's interpreted before the compiling is done, hence the "slow" start

        – Seblor
        Mar 14 at 13:13










      1




      1





      And it's really nice to see if you put both variants in separate files and run them.

      – floriangosse
      Mar 14 at 7:51





      And it's really nice to see if you put both variants in separate files and run them.

      – floriangosse
      Mar 14 at 7:51




      1




      1





      Are you sure this is a problem with JIT? My guess would have been initialisation of the console.

      – Bergi
      Mar 14 at 13:08





      Are you sure this is a problem with JIT? My guess would have been initialisation of the console.

      – Bergi
      Mar 14 at 13:08




      2




      2





      console already exists, it's native code, it doesn't have to be initialized. The V8 compiles your code Just-In-Time, so it's interpreted before the compiling is done, hence the "slow" start

      – Seblor
      Mar 14 at 13:13







      console already exists, it's native code, it doesn't have to be initialized. The V8 compiles your code Just-In-Time, so it's interpreted before the compiling is done, hence the "slow" start

      – Seblor
      Mar 14 at 13:13















      9














      You have an error in your program



      if (a[key].txt = 5)


      You are not checking if the txt property is equal to 5. You are setting the property to 5 which means you are finished after the first execution of the loop regardless.






      share|improve this answer
























      • you are right,I think I miss it when I copy ...

        – Johanna Feng
        Mar 14 at 9:52
















      9














      You have an error in your program



      if (a[key].txt = 5)


      You are not checking if the txt property is equal to 5. You are setting the property to 5 which means you are finished after the first execution of the loop regardless.






      share|improve this answer
























      • you are right,I think I miss it when I copy ...

        – Johanna Feng
        Mar 14 at 9:52














      9












      9








      9







      You have an error in your program



      if (a[key].txt = 5)


      You are not checking if the txt property is equal to 5. You are setting the property to 5 which means you are finished after the first execution of the loop regardless.






      share|improve this answer













      You have an error in your program



      if (a[key].txt = 5)


      You are not checking if the txt property is equal to 5. You are setting the property to 5 which means you are finished after the first execution of the loop regardless.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Mar 14 at 9:50









      MasterCassimMasterCassim

      7,47631728




      7,47631728













      • you are right,I think I miss it when I copy ...

        – Johanna Feng
        Mar 14 at 9:52



















      • you are right,I think I miss it when I copy ...

        – Johanna Feng
        Mar 14 at 9:52

















      you are right,I think I miss it when I copy ...

      – Johanna Feng
      Mar 14 at 9:52





      you are right,I think I miss it when I copy ...

      – Johanna Feng
      Mar 14 at 9:52











      2














      In JavaScript you can add or remove properties to objects dynamically. HashMaps are most memory efficient and fast data structures to access the properties. But dynamic nature of JavaScript makes it more difficult and slower. To fix this problem Nodejs V8 Engine internally uses JavaScript hidden classes and inline caching. Both the topics are quite vast to explain in this answer. So please find the blog link here and following is the awesome explanation of Nodejs v8 engine performance video.



      In one iteration you can not determine the performance of two algorithms in almost 99% cases. So I have just modified your code and iterated it for 11 times (which is also not sufficient) for the demo purpose. And you can see drastic change in the output.



      for (let i = 0; i <= 10; i++) {
      const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };

      console.time('Hash map access');
      let n = a['e'].txt;
      console.log(n, '<<n')
      console.timeEnd('Hash map access');

      console.time('For in loop');
      for (const key in a) {
      if (a[key].txt == 5) {
      const m = a[key];
      console.log(m, '<<m')
      break;
      }
      }
      console.timeEnd('For in loop');
      }


      Following is the out-put.



      5 '<<n'
      Hash map access: 8.580ms
      { txt: 5 } '<<m'
      For in loop: 4.301ms
      5 '<<n'
      Hash map access: 0.177ms
      { txt: 5 } '<<m'
      For in loop: 0.377ms
      5 '<<n'
      Hash map access: 0.170ms
      { txt: 5 } '<<m'
      For in loop: 0.196ms
      5 '<<n'
      Hash map access: 0.162ms
      { txt: 5 } '<<m'
      For in loop: 0.186ms
      5 '<<n'
      Hash map access: 0.483ms
      { txt: 5 } '<<m'
      For in loop: 0.465ms
      5 '<<n'
      Hash map access: 0.435ms
      { txt: 5 } '<<m'
      For in loop: 0.503ms
      5 '<<n'
      Hash map access: 0.500ms
      { txt: 5 } '<<m'
      For in loop: 0.471ms
      5 '<<n'
      Hash map access: 0.528ms
      { txt: 5 } '<<m'
      For in loop: 0.487ms
      5 '<<n'
      Hash map access: 0.492ms
      { txt: 5 } '<<m'
      For in loop: 0.494ms
      5 '<<n'
      Hash map access: 1.033ms
      { txt: 5 } '<<m'
      For in loop: 0.726ms
      5 '<<n'
      Hash map access: 0.484ms
      { txt: 5 } '<<m'
      For in loop: 0.649ms


      If you observe the output there is drastic change in hash-map access, first it was 8.580ms in second time it was 0.177ms. You can find that after first time hash-map is almost faster than "for in loop". (Sometimes it's not as my system is under a lot of pressure while runnig the code :) )



      Also I reversed the order, I put "For in Loop" first and then object [hashmap] following is the result.



      { txt: 5 } '<<m'
      For in loop: 16.390ms
      5 '<<n'
      Hash map access: 0.220ms
      { txt: 5 } '<<m'
      For in loop: 0.266ms
      5 '<<n'
      Hash map access: 0.186ms
      { txt: 5 } '<<m'
      For in loop: 0.277ms
      5 '<<n'
      Hash map access: 0.367ms
      { txt: 5 } '<<m'
      For in loop: 0.328ms
      5 '<<n'
      Hash map access: 0.249ms
      { txt: 5 } '<<m'
      For in loop: 0.947ms
      5 '<<n'
      Hash map access: 4.013ms
      { txt: 5 } '<<m'
      For in loop: 0.799ms
      5 '<<n'
      Hash map access: 0.532ms
      { txt: 5 } '<<m'
      For in loop: 0.565ms
      5 '<<n'
      Hash map access: 0.479ms
      { txt: 5 } '<<m'
      For in loop: 0.644ms
      5 '<<n'
      Hash map access: 0.609ms
      { txt: 5 } '<<m'
      For in loop: 0.624ms
      5 '<<n'
      Hash map access: 0.472ms
      { txt: 5 } '<<m'
      For in loop: 0.509ms
      5 '<<n'
      Hash map access: 0.458ms
      { txt: 5 } '<<m'
      For in loop: 0.568ms
      5 '<<n'
      Hash map access: 0.476ms


      We can see first for-in loop has taken 16.39ms while the second only 0.266ms. As mentioned in above answer instantiation takes a lot of time, we can easily validate by seeing these numbers.



      Conclusion is while writing the code in JavaScript for Nodejs v8 engine, if we don't add/remove properties on objects it will be more fast and efficient. Also code instantiation takes a lot of time while running the first time.






      share|improve this answer






























        2














        In JavaScript you can add or remove properties to objects dynamically. HashMaps are most memory efficient and fast data structures to access the properties. But dynamic nature of JavaScript makes it more difficult and slower. To fix this problem Nodejs V8 Engine internally uses JavaScript hidden classes and inline caching. Both the topics are quite vast to explain in this answer. So please find the blog link here and following is the awesome explanation of Nodejs v8 engine performance video.



        In one iteration you can not determine the performance of two algorithms in almost 99% cases. So I have just modified your code and iterated it for 11 times (which is also not sufficient) for the demo purpose. And you can see drastic change in the output.



        for (let i = 0; i <= 10; i++) {
        const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };

        console.time('Hash map access');
        let n = a['e'].txt;
        console.log(n, '<<n')
        console.timeEnd('Hash map access');

        console.time('For in loop');
        for (const key in a) {
        if (a[key].txt == 5) {
        const m = a[key];
        console.log(m, '<<m')
        break;
        }
        }
        console.timeEnd('For in loop');
        }


        Following is the out-put.



        5 '<<n'
        Hash map access: 8.580ms
        { txt: 5 } '<<m'
        For in loop: 4.301ms
        5 '<<n'
        Hash map access: 0.177ms
        { txt: 5 } '<<m'
        For in loop: 0.377ms
        5 '<<n'
        Hash map access: 0.170ms
        { txt: 5 } '<<m'
        For in loop: 0.196ms
        5 '<<n'
        Hash map access: 0.162ms
        { txt: 5 } '<<m'
        For in loop: 0.186ms
        5 '<<n'
        Hash map access: 0.483ms
        { txt: 5 } '<<m'
        For in loop: 0.465ms
        5 '<<n'
        Hash map access: 0.435ms
        { txt: 5 } '<<m'
        For in loop: 0.503ms
        5 '<<n'
        Hash map access: 0.500ms
        { txt: 5 } '<<m'
        For in loop: 0.471ms
        5 '<<n'
        Hash map access: 0.528ms
        { txt: 5 } '<<m'
        For in loop: 0.487ms
        5 '<<n'
        Hash map access: 0.492ms
        { txt: 5 } '<<m'
        For in loop: 0.494ms
        5 '<<n'
        Hash map access: 1.033ms
        { txt: 5 } '<<m'
        For in loop: 0.726ms
        5 '<<n'
        Hash map access: 0.484ms
        { txt: 5 } '<<m'
        For in loop: 0.649ms


        If you observe the output there is drastic change in hash-map access, first it was 8.580ms in second time it was 0.177ms. You can find that after first time hash-map is almost faster than "for in loop". (Sometimes it's not as my system is under a lot of pressure while runnig the code :) )



        Also I reversed the order, I put "For in Loop" first and then object [hashmap] following is the result.



        { txt: 5 } '<<m'
        For in loop: 16.390ms
        5 '<<n'
        Hash map access: 0.220ms
        { txt: 5 } '<<m'
        For in loop: 0.266ms
        5 '<<n'
        Hash map access: 0.186ms
        { txt: 5 } '<<m'
        For in loop: 0.277ms
        5 '<<n'
        Hash map access: 0.367ms
        { txt: 5 } '<<m'
        For in loop: 0.328ms
        5 '<<n'
        Hash map access: 0.249ms
        { txt: 5 } '<<m'
        For in loop: 0.947ms
        5 '<<n'
        Hash map access: 4.013ms
        { txt: 5 } '<<m'
        For in loop: 0.799ms
        5 '<<n'
        Hash map access: 0.532ms
        { txt: 5 } '<<m'
        For in loop: 0.565ms
        5 '<<n'
        Hash map access: 0.479ms
        { txt: 5 } '<<m'
        For in loop: 0.644ms
        5 '<<n'
        Hash map access: 0.609ms
        { txt: 5 } '<<m'
        For in loop: 0.624ms
        5 '<<n'
        Hash map access: 0.472ms
        { txt: 5 } '<<m'
        For in loop: 0.509ms
        5 '<<n'
        Hash map access: 0.458ms
        { txt: 5 } '<<m'
        For in loop: 0.568ms
        5 '<<n'
        Hash map access: 0.476ms


        We can see first for-in loop has taken 16.39ms while the second only 0.266ms. As mentioned in above answer instantiation takes a lot of time, we can easily validate by seeing these numbers.



        Conclusion is while writing the code in JavaScript for Nodejs v8 engine, if we don't add/remove properties on objects it will be more fast and efficient. Also code instantiation takes a lot of time while running the first time.






        share|improve this answer




























          2












          2








          2







          In JavaScript you can add or remove properties to objects dynamically. HashMaps are most memory efficient and fast data structures to access the properties. But dynamic nature of JavaScript makes it more difficult and slower. To fix this problem Nodejs V8 Engine internally uses JavaScript hidden classes and inline caching. Both the topics are quite vast to explain in this answer. So please find the blog link here and following is the awesome explanation of Nodejs v8 engine performance video.



          In one iteration you can not determine the performance of two algorithms in almost 99% cases. So I have just modified your code and iterated it for 11 times (which is also not sufficient) for the demo purpose. And you can see drastic change in the output.



          for (let i = 0; i <= 10; i++) {
          const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };

          console.time('Hash map access');
          let n = a['e'].txt;
          console.log(n, '<<n')
          console.timeEnd('Hash map access');

          console.time('For in loop');
          for (const key in a) {
          if (a[key].txt == 5) {
          const m = a[key];
          console.log(m, '<<m')
          break;
          }
          }
          console.timeEnd('For in loop');
          }


          Following is the out-put.



          5 '<<n'
          Hash map access: 8.580ms
          { txt: 5 } '<<m'
          For in loop: 4.301ms
          5 '<<n'
          Hash map access: 0.177ms
          { txt: 5 } '<<m'
          For in loop: 0.377ms
          5 '<<n'
          Hash map access: 0.170ms
          { txt: 5 } '<<m'
          For in loop: 0.196ms
          5 '<<n'
          Hash map access: 0.162ms
          { txt: 5 } '<<m'
          For in loop: 0.186ms
          5 '<<n'
          Hash map access: 0.483ms
          { txt: 5 } '<<m'
          For in loop: 0.465ms
          5 '<<n'
          Hash map access: 0.435ms
          { txt: 5 } '<<m'
          For in loop: 0.503ms
          5 '<<n'
          Hash map access: 0.500ms
          { txt: 5 } '<<m'
          For in loop: 0.471ms
          5 '<<n'
          Hash map access: 0.528ms
          { txt: 5 } '<<m'
          For in loop: 0.487ms
          5 '<<n'
          Hash map access: 0.492ms
          { txt: 5 } '<<m'
          For in loop: 0.494ms
          5 '<<n'
          Hash map access: 1.033ms
          { txt: 5 } '<<m'
          For in loop: 0.726ms
          5 '<<n'
          Hash map access: 0.484ms
          { txt: 5 } '<<m'
          For in loop: 0.649ms


          If you observe the output there is drastic change in hash-map access, first it was 8.580ms in second time it was 0.177ms. You can find that after first time hash-map is almost faster than "for in loop". (Sometimes it's not as my system is under a lot of pressure while runnig the code :) )



          Also I reversed the order, I put "For in Loop" first and then object [hashmap] following is the result.



          { txt: 5 } '<<m'
          For in loop: 16.390ms
          5 '<<n'
          Hash map access: 0.220ms
          { txt: 5 } '<<m'
          For in loop: 0.266ms
          5 '<<n'
          Hash map access: 0.186ms
          { txt: 5 } '<<m'
          For in loop: 0.277ms
          5 '<<n'
          Hash map access: 0.367ms
          { txt: 5 } '<<m'
          For in loop: 0.328ms
          5 '<<n'
          Hash map access: 0.249ms
          { txt: 5 } '<<m'
          For in loop: 0.947ms
          5 '<<n'
          Hash map access: 4.013ms
          { txt: 5 } '<<m'
          For in loop: 0.799ms
          5 '<<n'
          Hash map access: 0.532ms
          { txt: 5 } '<<m'
          For in loop: 0.565ms
          5 '<<n'
          Hash map access: 0.479ms
          { txt: 5 } '<<m'
          For in loop: 0.644ms
          5 '<<n'
          Hash map access: 0.609ms
          { txt: 5 } '<<m'
          For in loop: 0.624ms
          5 '<<n'
          Hash map access: 0.472ms
          { txt: 5 } '<<m'
          For in loop: 0.509ms
          5 '<<n'
          Hash map access: 0.458ms
          { txt: 5 } '<<m'
          For in loop: 0.568ms
          5 '<<n'
          Hash map access: 0.476ms


          We can see first for-in loop has taken 16.39ms while the second only 0.266ms. As mentioned in above answer instantiation takes a lot of time, we can easily validate by seeing these numbers.



          Conclusion is while writing the code in JavaScript for Nodejs v8 engine, if we don't add/remove properties on objects it will be more fast and efficient. Also code instantiation takes a lot of time while running the first time.






          share|improve this answer















          In JavaScript you can add or remove properties to objects dynamically. HashMaps are most memory efficient and fast data structures to access the properties. But dynamic nature of JavaScript makes it more difficult and slower. To fix this problem Nodejs V8 Engine internally uses JavaScript hidden classes and inline caching. Both the topics are quite vast to explain in this answer. So please find the blog link here and following is the awesome explanation of Nodejs v8 engine performance video.



          In one iteration you can not determine the performance of two algorithms in almost 99% cases. So I have just modified your code and iterated it for 11 times (which is also not sufficient) for the demo purpose. And you can see drastic change in the output.



          for (let i = 0; i <= 10; i++) {
          const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };

          console.time('Hash map access');
          let n = a['e'].txt;
          console.log(n, '<<n')
          console.timeEnd('Hash map access');

          console.time('For in loop');
          for (const key in a) {
          if (a[key].txt == 5) {
          const m = a[key];
          console.log(m, '<<m')
          break;
          }
          }
          console.timeEnd('For in loop');
          }


          Following is the out-put.



          5 '<<n'
          Hash map access: 8.580ms
          { txt: 5 } '<<m'
          For in loop: 4.301ms
          5 '<<n'
          Hash map access: 0.177ms
          { txt: 5 } '<<m'
          For in loop: 0.377ms
          5 '<<n'
          Hash map access: 0.170ms
          { txt: 5 } '<<m'
          For in loop: 0.196ms
          5 '<<n'
          Hash map access: 0.162ms
          { txt: 5 } '<<m'
          For in loop: 0.186ms
          5 '<<n'
          Hash map access: 0.483ms
          { txt: 5 } '<<m'
          For in loop: 0.465ms
          5 '<<n'
          Hash map access: 0.435ms
          { txt: 5 } '<<m'
          For in loop: 0.503ms
          5 '<<n'
          Hash map access: 0.500ms
          { txt: 5 } '<<m'
          For in loop: 0.471ms
          5 '<<n'
          Hash map access: 0.528ms
          { txt: 5 } '<<m'
          For in loop: 0.487ms
          5 '<<n'
          Hash map access: 0.492ms
          { txt: 5 } '<<m'
          For in loop: 0.494ms
          5 '<<n'
          Hash map access: 1.033ms
          { txt: 5 } '<<m'
          For in loop: 0.726ms
          5 '<<n'
          Hash map access: 0.484ms
          { txt: 5 } '<<m'
          For in loop: 0.649ms


          If you observe the output there is drastic change in hash-map access, first it was 8.580ms in second time it was 0.177ms. You can find that after first time hash-map is almost faster than "for in loop". (Sometimes it's not as my system is under a lot of pressure while runnig the code :) )



          Also I reversed the order, I put "For in Loop" first and then object [hashmap] following is the result.



          { txt: 5 } '<<m'
          For in loop: 16.390ms
          5 '<<n'
          Hash map access: 0.220ms
          { txt: 5 } '<<m'
          For in loop: 0.266ms
          5 '<<n'
          Hash map access: 0.186ms
          { txt: 5 } '<<m'
          For in loop: 0.277ms
          5 '<<n'
          Hash map access: 0.367ms
          { txt: 5 } '<<m'
          For in loop: 0.328ms
          5 '<<n'
          Hash map access: 0.249ms
          { txt: 5 } '<<m'
          For in loop: 0.947ms
          5 '<<n'
          Hash map access: 4.013ms
          { txt: 5 } '<<m'
          For in loop: 0.799ms
          5 '<<n'
          Hash map access: 0.532ms
          { txt: 5 } '<<m'
          For in loop: 0.565ms
          5 '<<n'
          Hash map access: 0.479ms
          { txt: 5 } '<<m'
          For in loop: 0.644ms
          5 '<<n'
          Hash map access: 0.609ms
          { txt: 5 } '<<m'
          For in loop: 0.624ms
          5 '<<n'
          Hash map access: 0.472ms
          { txt: 5 } '<<m'
          For in loop: 0.509ms
          5 '<<n'
          Hash map access: 0.458ms
          { txt: 5 } '<<m'
          For in loop: 0.568ms
          5 '<<n'
          Hash map access: 0.476ms


          We can see first for-in loop has taken 16.39ms while the second only 0.266ms. As mentioned in above answer instantiation takes a lot of time, we can easily validate by seeing these numbers.



          Conclusion is while writing the code in JavaScript for Nodejs v8 engine, if we don't add/remove properties on objects it will be more fast and efficient. Also code instantiation takes a lot of time while running the first time.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Mar 15 at 16:23

























          answered Mar 15 at 11:25









          Rahul RautRahul Raut

          298110




          298110























              2














              As you can see here, testing with JS can be really a mess.






              const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };

              let test = function(x) {
              console.log("Test "+x+" times")
              console.time('1');
              for(let i=0;i<x;i++) {
              let n = a['e'].txt;
              }

              console.timeEnd('1');
              console.time('2');

              for(let i=0;i<x;i++) {
              for (const key in a) {
              if (a[key].txt == 5) {
              const m = a[key];
              break;
              }
              }
              }
              console.timeEnd('2');
              }

              test(1)
              test(100)
              test(100000)
              test(100000)
              test(100000)
              test(10000000)








              share|improve this answer




























                2














                As you can see here, testing with JS can be really a mess.






                const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };

                let test = function(x) {
                console.log("Test "+x+" times")
                console.time('1');
                for(let i=0;i<x;i++) {
                let n = a['e'].txt;
                }

                console.timeEnd('1');
                console.time('2');

                for(let i=0;i<x;i++) {
                for (const key in a) {
                if (a[key].txt == 5) {
                const m = a[key];
                break;
                }
                }
                }
                console.timeEnd('2');
                }

                test(1)
                test(100)
                test(100000)
                test(100000)
                test(100000)
                test(10000000)








                share|improve this answer


























                  2












                  2








                  2







                  As you can see here, testing with JS can be really a mess.






                  const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };

                  let test = function(x) {
                  console.log("Test "+x+" times")
                  console.time('1');
                  for(let i=0;i<x;i++) {
                  let n = a['e'].txt;
                  }

                  console.timeEnd('1');
                  console.time('2');

                  for(let i=0;i<x;i++) {
                  for (const key in a) {
                  if (a[key].txt == 5) {
                  const m = a[key];
                  break;
                  }
                  }
                  }
                  console.timeEnd('2');
                  }

                  test(1)
                  test(100)
                  test(100000)
                  test(100000)
                  test(100000)
                  test(10000000)








                  share|improve this answer













                  As you can see here, testing with JS can be really a mess.






                  const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };

                  let test = function(x) {
                  console.log("Test "+x+" times")
                  console.time('1');
                  for(let i=0;i<x;i++) {
                  let n = a['e'].txt;
                  }

                  console.timeEnd('1');
                  console.time('2');

                  for(let i=0;i<x;i++) {
                  for (const key in a) {
                  if (a[key].txt == 5) {
                  const m = a[key];
                  break;
                  }
                  }
                  }
                  console.timeEnd('2');
                  }

                  test(1)
                  test(100)
                  test(100000)
                  test(100000)
                  test(100000)
                  test(10000000)








                  const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };

                  let test = function(x) {
                  console.log("Test "+x+" times")
                  console.time('1');
                  for(let i=0;i<x;i++) {
                  let n = a['e'].txt;
                  }

                  console.timeEnd('1');
                  console.time('2');

                  for(let i=0;i<x;i++) {
                  for (const key in a) {
                  if (a[key].txt == 5) {
                  const m = a[key];
                  break;
                  }
                  }
                  }
                  console.timeEnd('2');
                  }

                  test(1)
                  test(100)
                  test(100000)
                  test(100000)
                  test(100000)
                  test(10000000)





                  const a = { a: { txt: 1 }, b: { txt: 2 }, c: { txt: 3 }, d: { txt: 4 }, e: { txt: 5 }, f: { txt: 6 } };

                  let test = function(x) {
                  console.log("Test "+x+" times")
                  console.time('1');
                  for(let i=0;i<x;i++) {
                  let n = a['e'].txt;
                  }

                  console.timeEnd('1');
                  console.time('2');

                  for(let i=0;i<x;i++) {
                  for (const key in a) {
                  if (a[key].txt == 5) {
                  const m = a[key];
                  break;
                  }
                  }
                  }
                  console.timeEnd('2');
                  }

                  test(1)
                  test(100)
                  test(100000)
                  test(100000)
                  test(100000)
                  test(10000000)






                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Mar 15 at 16:50









                  ArthurArthur

                  2,88531837




                  2,88531837






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Stack Overflow!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55157295%2fwhy-is-searching-for-a-value-in-an-object-by-key-slower-than-using-for-in-in-j%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      is 'sed' thread safeWhat should someone know about using Python scripts in the shell?Nexenta bash script uses...

                      How do i solve the “ No module named 'mlxtend' ” issue on Jupyter?

                      Pilgersdorf Inhaltsverzeichnis Geografie | Geschichte | Bevölkerungsentwicklung | Politik | Kultur...