Just see following test.

Environment

  • OS: 4.15.0-47-generic #50-Ubuntu SMP.
  • CPU: Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz
  • NodeJs: 10.15.3

Normal

function f() {}

async function main() {
    let tm = -Date.now();
    for (let i = 0; i < 100000; i++) {
        f();
    }
    tm += Date.now();
    console.log(tm);
}
main()
$ node test.js
3

With operations

function f() {
    a = [];
    for (let i = 0; i < 30; i++) { a.push(i); }
}

async function main() {
    let tm = -Date.now();
    for (let i = 0; i < 100000; i++) {
        f();
    }
    tm += Date.now();
    console.log(tm);
}
main()

$ node test.js
27

With await

function f() {}

async function main() {
    let tm = -Date.now();
    for (let i = 0; i < 100000; i++) {
        await f();
    }
    tm += Date.now();
    console.log(tm);
}
main()
$ node test.js
19

With async/await

async function f() {}

async function main() {
    let tm = -Date.now();
    for (let i = 0; i < 100000; i++) {
        await f();
    }
    tm += Date.now();
    console.log(tm);
}
main()
$ node test.js
26
[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

Throwing exception in C++ is very expensive operation. But, "try... catch..." itself doesn't drain performance if exception is not thrown. So, "Throwing exception" should not be used for just convenience in coding!! This should be used only to handle unexpected and not-often-raised exception!

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

▶ Performance gab between using 'enum' and "using '#define' in Visual C++ 7.0
Environment : CPU: Intel 2.8G

Using enum:
    Number of enum items := 100,000 -> compiling takes very long time.
    Number of enum items := 10,000 -> very quick.
Using define
    Very quick even if number of defined items reaches 100,000.

Experimentally, if number of enum items are larger than specific threshold, compiling performance of VC++ 7.0 drops dramatically. So in this case, we would better to change 'enum' into '#define'.

▶ Order of finding 'include directory' in VC++ 7.0
"highest priority is directory where currently issued file is in.".
For example, lets consider following directory structure.

directory : xxx/src
=> a.c, c.h
directory : xxx/inc
=> b.h, c.h

(Let's assume that "xxx/inc" is added at "additional include directory").
"xxx/inc/b.h" and "xxx/inc/c.h" is used to compile "a.c". Even though compiler try to compile "a.c", "b.h" is issued file during parsing "b.h". And, "b.h" includes "c.h". So "c.h" in the directory where "b.h" is in, is included, because currently issued file is "b.h".

▶ Case that '.c' file and '.cpp' file whose basename are same, are in one VC Project in Visual 2005 Express C++.
For example, if there are 'a.c' and 'a.cpp' in one project, MSVC recognizes only '.cpp' file (based on experimental result). (I think the reason is that default compiler of VC is 'cpp' compiler.)
So, even if we modify 'a.c' and build, nothing is compiled because MSVC keep it's eyes on 'a.cpp' - it is not changed. (--> It's MSVC's bug!!)

▶ There is no way to compile one file with several different options in VC project. So we should use 'command line' to do this.

'Domain > Win32' 카테고리의 다른 글

[Win32][Tips] Creating Window...  (0) 2007.06.27
[Win32] IME Active중 VK Code얻기  (0) 2007.06.25
[Win32] 한글 입력하기  (0) 2007.06.23
[Tips] Cross-Compiling on Windows for Linux  (0) 2007.06.20
[Tips] cygwin 'make' issue  (0) 2007.06.13

+ Recent posts