반짝임과 불행 OOP - 페이지 3

 
Integer :

사실 테스트한 것은 컴파일러가 아니라 하나의 문제를 해결하기 위한 두 가지 방법이었습니다. 냉장고가 우우우우우우우우우우우우우우우우우우우악~잉~잉~잉~잉~잉~잉~잉~윙윙윙윙윙윙윙윙윙윙윙윙윙윙대는거는중요하지않습니다. 냉장고가얼어붙는가는중요합니다.

문제는 손가락과 소음에서 빨려 ...

가상 함수는 인라인되지 않으므로 최적화를 켠 상태에서 전환이 잘 되면 간단한 예제와 비교하는 것은 의미가 없습니다. 이 시간.

누가 OOP가 더 빠르다고 했습니까? 더 편리하고 논리적이지만 더 빠르지는 않습니다. 이것은 2개입니다.

사용하지 마십시오.

 
Integer :
그 후 두 가지 테스트 옵션이 더 있었습니다. 2 - 비어 있지 않은 기능, 3 - 고유한 기능의 경우 결과는 비슷합니다. 옵션 1은 여전히 C#에서 수행 되었지만 결과는 반대였습니다.

나는 이러한 옵션을 보았다. 또한 인라인 방식에도 적합하고 최적화되어 있습니다.

C# 변형은 코드 최적화 프로그램에 대한 오해로 인한 또 다른 오해의 소지가 있음을 보여줍니다. 코드는 표시되지 않았으며 dot-net 컴파일러에도 몇 배 더 많은 최적화 방법이 있습니다. 간단한 경우에 가상 기능을 일반 기능으로 변환하는 간단한 경우의 예를 들었을 뿐입니다. 또한 이 최적화(이 테스트와 같은 간단한 경우)를 켜고 "가상" 방법이 갑자기 직접 방법을 추월하는 방법도 볼 수 있습니다.

 
TheXpert :

문제는 손가락과 소음에서 빨려 ...

가상 함수는 인라인되지 않으므로 최적화를 켠 상태에서 전환이 잘 되면 간단한 예제와 비교하는 것은 의미가 없습니다. 이 시간.

누가 OOP가 더 빠르다고 했습니까? 더 편리하고 논리적이지만 더 빠르지는 않습니다. 이것은 2개입니다.

사용하지 마십시오.

예, 이것은 전혀 문제가 되지 않습니다. 결과와 결론으로 실험하십시오.

좋아요, 싫어요. 빠른 대신 느린 것을 사용하는 것은 논리적이지 않습니다.

 
Renat :

나는 이러한 옵션을 보았다. 또한 인라인 방식에도 적합하고 최적화되어 있습니다.

C# 변형은 코드 최적화 프로그램에 대한 오해로 인한 또 다른 오해의 소지가 있음을 보여줍니다. 코드는 표시되지 않았으며 dot-net 컴파일러에도 몇 배 더 많은 최적화 방법이 있습니다. 간단한 경우에 가상 기능을 일반 기능으로 변환하는 간단한 경우의 예를 들었을 뿐입니다. 또한 이 최적화(이 테스트와 같은 간단한 경우)를 켜고 "가상" 방법이 갑자기 직접 방법을 추월하는 방법도 볼 수 있습니다.

내가 얻는 결과가 무엇이든 잘못되고 오해의 소지가 있는 것 같습니다.

- 무엇을 위해?

- 인도인입니다.

(xf 론 레인저)

아무리 노력해도 가상 방식보다 스위치를 통해 느리게 작동하도록 할 수 없습니다. 시도했지만 죄송합니다. 작동하지 않았습니다.

 

다음은 애플리케이션의 첫 번째 C# 테스트입니다. 결과 는 다음과 같습니다.

파일:
test.zip  66 kb
 

증거는 반대편에 있을 것입니다. 또는 다시 말하지만.

대체로 사실만이 관심 대상입니다.

OOP가 더 느리다는 것을 이미 알고 있지만 매우 구체적인 편의를 제공합니다.

 
Vinin :

증거는 반대편에 있을 것입니다.

무엇의 증거?
 
TheXpert :
무엇의 증거?
Andrei, 당신은 Dima가 틀렸다는 것을 증명하고 싶은 욕망이 있습니다. 그런 다음 가져와
 

OOP, 쓰기 장난감이 필요한 이유는 무엇입니까? )

 

어쨌든 문제가 제기 된 것은 좋습니다.

우리는 컴파일러와 최적화 프로그램을 개선하기 위해 지속적으로 노력하고 있습니다. 지금은 가상 메서드 호출 최적화에 집중하겠습니다(많은 가상 메서드가 직접 메서드로 전환될 수 있음).