많은 작은 물체의 생성을 최소화해야합니까?

작은 (1000) 개의 작은 개체를 자주 만드는 무언가를 작성할 때 성능을 위해 최소화해야합니까? 특히 저급 데스크톱에서 고급 데스크톱 또는 모바일에 이르기까지 어떤 시스템에서 실행될 시스템을 모를 경우. 모바일의 경우 많은 객체를 만들면 성능이 약간 저하된다고 들었습니다.하지만 그것이 얼마나 사실인지는 모르겠습니다.

이 아이디어를 잘 보여주는 예가 있습니다. 그래픽 프로그램에서 모든 드로잉에 이상적으로 사용되는 메소드가 있다고 가정하십시오 drawPixel(Point). 1000의 포인트가 생성 될 수 있으며 초당 60 회 이상 호출 될 수있는 게임 에서처럼 반복 될 수 있습니다. 또는 drawPixel(int x, int y)많은 Point 객체의 생성을 최소화하는 데 사용할 수 있습니다.

객체 지향 디자인에서는 Point를 사용하는 것이 좋습니다. 그러나 기본 유형을 사용하면 성능이 향상 될 수 있습니다. 대부분의 경우 성능 향상은 무시할 수 있지만 모바일 또는 구형 컴퓨터와 같은 것은 확실하지 않습니다. 이와 같은 작업으로 인한 성능 이점은 무엇이며 고려해야 할 사항입니까?

일반적으로 아니요 , 성능 손실이 발생할 우려가있는 개체를 만들지 마십시오. 여기에는 몇 가지 이유가 있습니다.

1. 객체를 사용하는 것은 Java를 사용하는 시점입니다. 그것들을 선제 적으로 피하는 것은 Java를 사용하기로 한 결정이 시작하기에 옳지 않았 음을 나타내는 신호입니다.
2. 성능 문제는 악명 예측하기 어렵다. 병목 현상이 있다고 가정 하지 마십시오 . 항상 측정하십시오. 성능 엔지니어링은 거의 항상 정확한 위치에서 약간의 변경을 수행해야합니다. 실험없이 약물의 효과를 예측할 수있는 것 이상을 측정하지 않으면 올바른 장소를 예측할 수 없습니다.
3. 객체 생성 비용이 과대 평가되었습니다. 최신 JVM에서는 기본적으로 포인터를 증가시키는 데 도움이됩니다 (세대 가비지 수집기의 경우 관리 비용도 간단합니다). 인터넷에는 객체를 피하고 객체 풀링 등을 사용하도록 조언하는 많은 텍스트가 있습니다.이 조언은 때때로 1990 년대에 옳았습니다. 오늘날 그것은 대부분 쓸모가 없습니다. 객체를 피하거나 직접 관리하여 도입 된 추가 개발 비용과 복잡성을 정당화하기에 충분한 성능을 얻을 가능성은 거의 없습니다.

즉, 무언가를 물건으로 만드는 것이 처음에는 의미가없는 곳이 있습니다. 두 개의 좌표를 그리기 루틴에 전달하는 경우가 있습니다. 좌표 쌍에는 독립적 인 존재가없고, 정체성이 없으며, 한 번만 사용 된 다음 즉시 버려지는 등입니다.

이 경우에는 반드시 int객체로 감싸지 말고 두 s를 전달하십시오 . OOP의 요점은 모든 것이 객체 여야한다는 것이 아닙니다. 요점은 객체가 데이터 표현 문제에 대한 자연스러운 해결책 인 곳에서 개발을 더 쉽게 만든다는 것입니다. 의미가있는 물체는 피하십시오. 그렇지 않은 물체는 소개하지 마십시오.

코드를 작성하기 전에 성능에 대한 영향을 고려할 때는 수행중인 작업을 모른다고 가정해야합니다.

자바와 프리미티브의 객체에는 공간 오버 헤드가 매우 작습니다. 개체가 작을수록 오버 헤드 비율이 커집니다. 그러나 오래 전에 배가 된 n은 n에 n을 곱한 것보다 아무것도 없다는 것을 배웠다.

예, 크기에 절반의 영향을 미쳤거나 4 분의 1 정도의 시스템에 문제가 생길 수 있습니다. 이 문제에 대한 복잡한 해결책은 잘 받아들이지 않을 것입니다. 특히 그러한 코드에 들어가는 것은 혼란 스러울 것입니다. 혼란스러운 프로그래머는 잘못된 코드를 작성합니다. n log n 코드 여야하는 n 곱하기 n 코드를 작성합니다. 그리고 그들은 그것을 더 오래 걸립니다.

이제 당신이 대화 할 수있는 대부분의 시간을 들여다 볼 필요가없는 멋진 상자에 맞는 몇 가지 트릭으로 공간을 절약 할 수 있다면. 그것이 상자라면 그 상자가 더 잘 작동 할 때 다른 상자로 교체 할 수 있습니다. 나는 그것을 지불 할 수도 있습니다.

필자가 수행 한 성능 조정 ( 예 )에서 메모리 관리가 주요 범인이되는 것은 매우 쉽습니다. 나는 그들이 새로운 연산자와 가비지 컬렉터를 얼마나 미치게 조정했는지 상관하지 않습니다 . 가장 빠른 계산은 계산이 아닙니다. 따라서 메모리 관리자가 시간이 많이 걸리고 객체를 만드는 것을 피할 수 없다면 끊임없이 새로운 객체를 만드는 대신 재사용하는 방법을 찾습니다.

객체 를 만들어야하는 경우에만이 작업을 수행 합니다. 그래픽의 경우 일반적으로 그렇지 않습니다. IMHO, 그래픽되어야 그려 하지 내장 . 물론 그림은 점, 점을 연결하는 선, 다각형, 텍스트 등으로 구성되어 있다고 말할 수 있습니다. 그렇다고 해서 객체 를 그리기 전에 객체 를 만들 수있는 대안은 없습니다 . 그냥 그립니다.

페인트 방법이 있습니다. 이를 무시하고 모든 것을 비트 맵에 그린 다음 화면으로 전송을 차단합니다. 순간적으로 보입니다. 마우스 입력의 경우 클릭, 드래그 등을 감지하기 위해 재정의하는 메소드가 있습니다.

OOP는 특정 이유로 좋은 아이디어입니다. 이러한 이유가 모든 상황에 적용되는 것은 아닙니다 .

계속해서 작은 할당을 사용하십시오. 최신 메모리 관리자, 특히 고도로 최적화 된 Java 객체 관리자는 매우 효율적입니다. 작업중인 프로그램에 대한 주요 성능 최적화를 저장하십시오.

전반적인 성능이 적절할 가능성이 극히 높습니다. 당신이 그렇지 않은 것을 발견하면, 다음, 오직 다음 , 코드의 성능을 프로파일 링. 소프트웨어 개발의 오랜 경력에서 병목 현상이 거의 예상치 못한 부분임을 알았습니다.

한때 팀 구성원이 며칠 동안 개체 구성원 조회를 20 배 빠르게 만드는 데 시간을 보냈습니다. 성공! 그러나 실제 사용에서 최상의 전체 속도 향상은 100 분의 1 퍼센트로 측정되었습니다. 멤버 당 메모리 할당 당 더 큰 속도가 필요했기 때문에 변경 사항이 즉시 취소되었습니다.

간단합니다. 1000 개의 작은 개체가 필요한 경우 1000 개의 작은 개체를 만들고 걱정하지 않아도됩니다. 100 개의 작은 개체 가 필요한 경우 1000 개의 작은 개체를 만드는 것은 어리석은 일입니다. 필요하지 않은 개체를 만드십시오.

성능이 걱정되는 경우 (및 성능이 걱정되지 않는 경우) 한 곳에서 한 번만 작성 하면 모든 코드를 더 간단하고 이해하기 쉽게 작성해야합니다. 그런 다음 성능 문제가있는 경우 측정 하면 성능 문제가 발생하는 장소 가 하나 있어 더 쉽게 만들 수 있으며 변경해야하는 장소가 하나만있을 수 있습니다. 또는 측정 결과 이곳에서 아무런 문제가 발생하지 않았으므로 완료되었습니다.