KR100913111B1 - Method for creating resource file for optimizing memory - Google Patents

Method for creating resource file for optimizing memory Download PDF

Info

Publication number
KR100913111B1
KR100913111B1 KR1020070125908A KR20070125908A KR100913111B1 KR 100913111 B1 KR100913111 B1 KR 100913111B1 KR 1020070125908 A KR1020070125908 A KR 1020070125908A KR 20070125908 A KR20070125908 A KR 20070125908A KR 100913111 B1 KR100913111 B1 KR 100913111B1
Authority
KR
South Korea
Prior art keywords
resource
file
resource object
byte
memory
Prior art date
Application number
KR1020070125908A
Other languages
Korean (ko)
Other versions
KR20090059195A (en
Inventor
최동완
송찬호
Original Assignee
주식회사 에이앤비소프트
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 에이앤비소프트 filed Critical 주식회사 에이앤비소프트
Priority to KR1020070125908A priority Critical patent/KR100913111B1/en
Publication of KR20090059195A publication Critical patent/KR20090059195A/en
Application granted granted Critical
Publication of KR100913111B1 publication Critical patent/KR100913111B1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44568—Immediately runnable code
    • G06F9/44578—Preparing or optimising for loading
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

본 발명은 메모리 최적화를 위한 리소스 파일 생성방법에 관한 것으로서, 보다 상세하게는 어플리케이션(application)을 실행하는데 필요한 여러 가지 리소스(resource) 파일을 최적의 포맷으로 생성함으로써 중앙처리장치가 메인 메모리로부터 리소스를 로딩하여 실행하는 속도를 크게 향상시킬 수 있도록 해주는 방법에 관한 것이다.The present invention relates to a method for generating a resource file for memory optimization, and more particularly, by generating various resource files necessary for executing an application in an optimal format, the central processing unit generates resources from the main memory. It's about how to make it significantly faster to load and run.

상기한 목적을 달성하기 위한 기술적 구성은, (a) 각각의 리소스 객체(Resource object) 내에 저장된 리소스 데이터들을 순차적으로 로딩하여 리소스 객체별로 바이트 정렬(Byte alignment)하는 단계; (b) 상기 바이트 정렬된 각각의 리소스 객체들 간에도 바이트 정렬을 통하여 결합시킴으로써 하나의 리소스 파일(Resource file)을 만드는 단계; (c) 상기 각각의 리소스 객체 내부에서 참조하는 다른 리소스 객체에 대한 인덱스 정보를 상기 리소스 파일을 구성하는 첫 번째 리소스 객체의 시작번지를 기준으로 한 오프셋(offset)으로 계산하여 상기 각각의 리소스 객체 내에 직접 저장하는 단계;를 포함한다. Technical composition for achieving the above object, (a) sequentially loading the resource data stored in each resource object (Resource object) by byte alignment (Byte alignment) for each resource object (Byte alignment); (b) creating a single resource file by combining through byte alignment even between each of the byte aligned resource objects; (c) calculate index information of another resource object referred to inside each resource object as an offset based on a start address of a first resource object constituting the resource file, and then calculate the index information in each resource object. And storing directly.

메모리, 리소스, 바이트 정렬, 오프셋 Memory, resources, byte alignment, offset

Description

메모리 최적화를 위한 리소스 파일 생성방법{Method for creating resource file for optimizing memory}Method for creating resource file for optimizing memory}

본 발명은 메모리 최적화를 위한 리소스 파일 생성방법에 관한 것으로서, 보다 상세하게는 어플리케이션(application)을 실행하는데 필요한 여러 가지 리소스(resource) 파일을 최적의 포맷으로 생성함으로써 중앙처리장치가 메인 메모리로부터 리소스를 로딩하여 실행하는 속도를 크게 향상시킬 수 있도록 해주는 방법에 관한 것이다. The present invention relates to a method for generating a resource file for memory optimization, and more particularly, by generating various resource files necessary for executing an application in an optimal format, the central processing unit generates resources from the main memory. It's about how to make it significantly faster to load and run.

컴퓨터에서 실행되는 대부분의 어플리케이션은 크게 실행 코드(Execution code)와 리소스(Resource)로 구성된다. 실행 코드는 어플리케이션을 실제로 구동하는 프로그램 코드로서 자바, C++ 과 같은 프로그램 언어(program language)로 코딩되어 전용 컴파일러에 의해 파일로 생성된다. 리소스는 중앙처리장치에서 상기 실행 코드를 실행하는데 필요로 하는 각종 변수(Variable), 스트링(String), 비트맵(Bitmap), 멀티미디어(multimedia) 데이터들을 총망라한다. Most applications running on a computer are largely composed of execution code and resources. Execution code is the program code that actually runs the application. It is coded in a program language such as Java or C ++, and generated into a file by a dedicated compiler. A resource includes various variables, strings, bitmaps, and multimedia data required for executing the executable code in a central processing unit.

도 1에는 상기 어플리케이션의 실행 코드와 리소스를 구성하는 두 가지 방법이 비교 도시되어 있다. 1 illustrates two methods for constructing an execution code and a resource of the application.

고전적인 방법은 도 1의 (a)와 같이 실행 코드(2)와 리소스(3)를 하나의 어플리케이션 파일(1)로 구성하는 것으로, 실행 코드(2)에서 리소스(3)를 직접 읽어와 사용할 수 있다. 이러한 방법에 따르면, 실행 파일의 관리가 비교적 간단하고 사용자가 리소스를 함부로 수정해서 실행 파일이 비정상적으로 수행되도록 하는 것을 방지할 수 있는 장점이 있다. The classical method is to configure the executable code 2 and the resource 3 into one application file 1 as shown in FIG. 1A. The resource 3 can be read directly from the executable code 2 and used. Can be. According to this method, there is an advantage that the management of the executable file is relatively simple, and the user can prevent the executable file from being abnormally executed by modifying the resource.

그러나, 게임 프로그램과 같이 대용량의 리소스를 사용하는 경우에는, 일부 리소스를 수정할 때마다 전체 어플리케이션 파일(1)을 다시 컴파일해야 하는 등 리소스 관리가 복잡해지는 단점이 있다. However, in the case of using a large amount of resources such as a game program, there is a disadvantage in that resource management becomes complicated, such as the need to recompile the entire application file 1 every time some resources are modified.

따라서, 최근에는 리소스의 체계적인 관리를 위하여 도 1의 (b)와 같이 어플리케이션 파일(4)은 실행 코드로만 구성하고, 연관성 있는 여러 리소스들을 별도의 리소스 파일(5)로 생성하여 관리하는 방법이 사용된다. 이러한 방법에 따르면, 어플리케이션 파일(4)은 리소스를 파일 형태로 읽어와 실행하고 사용자는 해당 리소스 파일(5)만을 수정하여 컴파일할 수 있기 때문에, 체계적인 리소스 관리가 가능하고 다양한 언어 및 스킨을 지원할 수 있다는 장점이 있다. Therefore, recently, in order to systematically manage resources, as shown in FIG. 1B, the application file 4 is composed of only executable code, and various related resources are generated and managed as a separate resource file 5. do. According to this method, since the application file 4 reads and executes the resource in the form of a file, and the user can modify and compile only the resource file 5, it is possible to systematically manage resource and support various languages and skins. There is an advantage.

다만, 리소스를 복수개의 파일로 관리하게 되므로 리소스 파일을 메인 메모리로 읽어올 때 각각의 파일마다 메모리가 할당되어 메모리 단편화가 발생하는 등 저장공간이 비효율적으로 사용되는 단점이 있다. However, since the resource is managed as a plurality of files, when the resource file is read into the main memory, memory is allocated to each file and memory fragmentation occurs, such that the storage space is inefficiently used.

또한, 리소스 간에 참조가 발생하는 경우에 종래에는 중앙처리장치에서 그 참조 관계를 해석하기 위하여 메모리 액세스 횟수가 증가하여 리소스의 로딩 및 실행 속도가 저하되는 단점이 있다. 종래의 리소스 간 참조 방법과 그 문제점을 도 2 를 참조로 간단히 설명한다. In addition, when a reference occurs between resources, a conventional CPU has a disadvantage in that the number of memory accesses is increased in order to interpret the reference relationship, thereby reducing the loading and execution speed of the resource. The conventional inter-resource reference method and its problems will be briefly described with reference to FIG.

도 2의 (a)에는 컴퓨터의 메인 메모리(6)에 리소스 객체 A, B, C, F, G, I, S를 위한 공간이 할당되고, 리소스 객체 A는 그 내부에서 리소스 객체 B, S를 순차적으로 참조하며, 리소스 객체 G는 리소스 객체 F, I를 순차적으로 참조하고, 리소스 객체 C는 리소스 객체 F를 참조하도록 구성된 일 예가 도시되어 있다.In FIG. 2A, spaces for resource objects A, B, C, F, G, I, and S are allocated to the main memory 6 of the computer, and the resource object A stores resource objects B and S therein. Reference is made sequentially, an example is shown in which a resource object G is configured to refer to resource objects F and I sequentially, and a resource object C is configured to refer to a resource object F.

여기서, 리소스 객체(Resource object)라 함은 연관성 있는 리소스 데이터들의 집합을 의미하는 것으로 정의한다. 예를 들어, C++ 언어로 코팅된 어플리케이션에서 하나의 구조체(Structure)를 구성하는 자료 데이터들의 집합일 수 있고, 게임 어플리케이션에서는 캐릭터(Caracter)의 연속 동작을 나타내는 비트맵 데이터들의 집합일 수도 있다. 정리하면, 연관성 있는 복수개의 리소스 데이터가 모여 하나의 리소스 객체를 이루고, 연관성 있는 복수개의 리소스 객체가 모여 하나의 리소스 파일을 구성한다. Here, the resource object is defined as meaning a set of related resource data. For example, it may be a set of data data constituting a structure in an application coated with a C ++ language, or may be a set of bitmap data representing a continuous operation of a character in a game application. In summary, a plurality of related resource data are gathered to form one resource object, and a plurality of related resource objects are gathered to form one resource file.

도 2의 (b)에는 상기 리소스 객체를 포함하도록 생성된 실제 리소스 파일(7)의 포맷이 도시되어 있다. 어플리케이션 파일과 별도로 생성되는 리소스 파일(7)에는 각각의 리소스 객체에 대한 실제 정보 이 외에도 그 내부에서 참조하는 다른 리소스 객체에 대한 키 정보가 저장된다. 예를 들어, 리소스 객체 A가 저장되는 공간에는 리소스 객체 A의 실제 정보와 함께 리소스 객체 A의 내부에서 참조하는 리소스 객체 B와 S의 Key 정보가 저장된다. 2 (b) shows the format of the actual resource file 7 created to contain the resource object. In addition to the actual information about each resource object, the resource file 7 generated separately from the application file stores key information about other resource objects referred to therein. For example, in the space where the resource object A is stored, key information of the resource objects B and S which are referred to inside the resource object A is stored together with the actual information of the resource object A.

그리고, 각각의 리소스 객체 A,B,C,F,G,I,S의 Key 정보는 별도의 인덱스 파일(8)로 관리된다. 이 인덱스 파일(8)에 저장되는 정보는 상기한 리소스 객체의 Key 정보 이외에도 리소스 파일 내에 해당 리소스 객체의 위치, 리소스 객체의 종류, 크기 등이 포함된다. 이러한 인덱스 정보를 이용하면 종류나 크기가 다른 리소스 객체들을 하나로 묶어서 저장할 수 있고, 리소스 객체 간의 참조 관계도 해석할 수 있다.The key information of each resource object A, B, C, F, G, I, S is managed by a separate index file 8. The information stored in the index file 8 includes not only the key information of the resource object but also the location of the resource object, the type and size of the resource object in the resource file. Using this index information, resource objects of different types or sizes can be bundled together and stored, and reference relationships between resource objects can be analyzed.

이와 같이 생성된 종래의 리소스 파일 포맷에 따라 리소스 객체를 참조하는 과정을 설명한다. 먼저, 중앙처리장치는 해당 리소스 파일(7)에 대한 인덱스 파일(8)을 메인 메모리로 읽어와 저장한다. 어플리케이션을 실행하는 과정에서 리소스 파일(7)에 포함된 리소스 객체 A를 사용하고자 하는 때에는 상기 인덱스 파일(8)에 저장된 리소스 객체 A의 인덱스 정보를 이용하여 메인 메모리에 저장된 리소스 객체 A를 액세스한다(과정 ①). A process of referring to a resource object according to the conventional resource file format generated as described above will be described. First, the CPU reads and stores the index file 8 for the resource file 7 into the main memory. When the resource object A included in the resource file 7 is to be used in the process of executing the application, the resource object A stored in the main memory is accessed using the index information of the resource object A stored in the index file 8 ( Process ①).

리소스 객체 A의 내부에서 리소스 객체 B를 참조하는 때에는, 중앙처리장치가 상기 리소스 객체 A에 저장된 리소스 객체 B의 Key 정보를 이용하여 상기 인덱스 파일(8)을 액세스하고(과정 ②), 상기 인덱스 파일(8)에 저장되어 있던 리소스 객체 B의 인덱스 정보(시작번지)를 이용하여 메인 메모리에 저장된 리소스 객체 B를 액세스한다(과정 ③). 계속하여 리소스 객체 A의 내부에서 리소스 객체 S를 참조하는 때에는 상기 리소스 객체 B를 참조하는 것과 동일한 작업이 반복된다(과정 ④,⑤). When referencing the resource object B inside the resource object A, the central processing unit accesses the index file 8 using the key information of the resource object B stored in the resource object A (step ②), and the index file The resource object B stored in the main memory is accessed using the index information (start address) of the resource object B stored in (8) (process ③). Subsequently, when referring to the resource object S from the inside of the resource object A, the same operation as that of referring to the resource object B is repeated (steps 4 and 5).

도 2의 (b)에 도시되어 있지는 않지만, 리소스 객체 C,G도 동일한 방법으로 그 내부에서 참조하는 다른 리소스 객체(F 및 F,I)를 액세스한다.Although not shown in FIG. 2B, the resource objects C and G also access other resource objects F and F and I referenced therein in the same manner.

이와 같이 실행되는 종래의 리소스 파일 참조 방법에 따르면, 하나의 리소스 객체를 로딩할 때마다 일일이 인덱스 파일(8)을 참조해야 하므로 메모리 액세스 횟수가 크게 증가하고, 이로 인해 어플리케이션의 전체 퍼포먼스가 저하되는 문제점이 있었다. According to the conventional method of referencing a resource file executed as described above, the index file 8 must be referred to each time one resource object is loaded, thereby increasing the number of memory accesses, thereby reducing the overall performance of the application. There was this.

본 발명은 이러한 문제점을 해결하기 위해 창안된 것으로서, 리소스 파일을 새로운 포맷으로 생성하여 별도의 인덱스 파일을 사용하지 않고도 각각의 리소스 객체에서 다른 리소스 객체를 직접 참조할 수 있도록 함으로써, 메모리를 최적화하여 궁극적으로 어플리케이션의 퍼포먼스를 향상시킬 수 있도록 해주는데 그 목적이 있다. The present invention was devised to solve this problem, and by optimizing memory by creating a resource file in a new format so that each resource object can directly refer to another resource object without using a separate index file. The goal is to improve the performance of your application.

또한, 본 발명은 각각의 리소스 객체를 바이트 정렬(Byte alignment)함으로써 중앙처리장치가 리소스 파일을 보다 효과적으로 액세스할 수 있도록 해주는데 또 다른 목적이 있다. It is another object of the present invention to allow the CPU to access resource files more effectively by byte alignment of each resource object.

상기한 목적을 달성하기 위한 본 발명의 기술구성은, (a) 각각의 리소스 객체(Resource object) 내에 저장된 리소스 데이터들을 순차적으로 로딩하여 리소스 객체별로 바이트 정렬(Byte alignment)하는 단계; (b) 상기 바이트 정렬된 각각의 리소스 객체들 간에도 바이트 정렬을 통하여 결합시킴으로써 하나의 리소스 파일(Resource file)을 만드는 단계; (c) 상기 각각의 리소스 객체의 내부에서 참조하는 다른 리소스 객체에 대한 인덱스 정보를 상기 리소스 파일을 구성하는 첫 번째 리소스 객체의 시작번지를 기준으로 한 오프셋(offset)으로 계산하여 상기 각각의 리소스 객체 내에 직접 저장하는 단계;를 포함하여 구성된다.Technical configuration of the present invention for achieving the above object comprises the steps of (a) sequentially loading the resource data stored in each resource object (Resource object) by byte alignment (Byte alignment) for each resource object; (b) creating a single resource file by combining through byte alignment even between each of the byte aligned resource objects; (c) by calculating index information of another resource object referred to inside each resource object as an offset based on a start address of a first resource object constituting the resource file, wherein each resource object is calculated. And storing directly within.

또한, 상기 (a) 단계는, 상기 각각의 리소스 객체 내에 저장된 모든 리소스 데이터들을 로딩한 다음 어플리케이션에서 실제로 필요로 하는 데이터만을 추출하여 바이트 정렬하도록 구성된다.In addition, the step (a) is configured to load all the resource data stored in each resource object, and then extract only the data actually needed by the application and byte alignment.

또한, 상기 (b) 단계는, 상기 바이트 정렬된 각각의 리소스 객체를 참조되는 순서에 따라 재배열한 다음 이를 결합함으로써 하나의 리소스 파일을 생성하도록 구성된다. In addition, the step (b) is configured to generate one resource file by rearranging each of the byte-aligned resource objects in the order of reference and then combining them.

또한, 상기 (c) 단계는, 상기 첫 번째 리소스 객체의 시작번지가 가상의 메모리 주소가 되도록 구성된다.In addition, step (c) is configured such that the start address of the first resource object is a virtual memory address.

상기와 같이 구성된 본 발명의 메모리 최적화를 위한 리소스 파일 생성방법에 따르면, 메모리 공간을 적게 사용하면서도 리소스 파일의 로딩 및 실행 속도를 증가시켜 궁극적으로 어플리케이션의 퍼포먼스를 향상시켜준다. 이러한 본 발명의 효과는 모바일 장치와 같이 메모리의 용량이 한정되어 있는 시스템의 경우에 더욱 강력한 리소스 관리 수단을 제공해 준다.According to the resource file generation method for optimizing the memory of the present invention configured as described above, while increasing the loading and execution speed of the resource file while using less memory space ultimately improves the performance of the application. This effect of the present invention provides a more powerful resource management means in the case of a system having a limited memory capacity, such as a mobile device.

이하에서 첨부된 도면을 참조로 본 발명에 따른 바람직한 일 실시예를 보다 상세히 설명한다. 도 3은 본 발명에 따른 리소스 파일 생성방법을 도시한 순서도이 고, 도 4는 본 발명에 따른 바이트 정렬을 나타낸 도면이며, 도 5는 본 발명에 따른 리소스 파일의 포맷을 나타낸 도면이다.Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. 3 is a flowchart illustrating a method of generating a resource file according to the present invention, FIG. 4 is a diagram illustrating byte alignment according to the present invention, and FIG. 5 is a diagram showing a format of a resource file according to the present invention.

도 3에 도시된 바와 같이, 본 발명에 따른 메모리 최적화를 위한 리소스 파일 생성방법은 크게 각각의 리소스 객체를 바이트 정렬하는 단계(S10), 바이트 정렬된 각각의 리소스 객체를 결합시켜 하나의 리소스 파일을 만드는 단계(S20) 및 리소스 객체 간의 참조를 위한 인덱스 정보를 계산하여 각각의 리소스 객체 내에 직접 저장하는 단계(S30)로 구성된다.As shown in FIG. 3, in the method of generating a resource file for memory optimization according to the present invention, a step of byte sorting each resource object is large (S10), and one resource file is combined by combining each resource object of the byte alignment. A step S20 and a step of calculating index information for reference between resource objects and directly storing the index information in each resource object are included.

상기 S10 단계는 리소스 객체를 구성하는 일련의 리소스 데이터를 바이트 정렬하는 단계로서, 보다 상세하게는 본 발명에 따른 리소스 파일 생성용 컴파일러가 각각의 리소스 객체 내에 저장된 리소스 데이터들을 순차적으로 로딩하여 리소스 객체별로 바이트 정렬을 행한다. The step S10 is a step of byte-aligning a series of resource data constituting a resource object, and more specifically, the resource file generation compiler according to the present invention sequentially loads resource data stored in each resource object and then for each resource object. Byte alignment is performed.

상기 리소스 객체(Resource object)는 연관성 있는 리소스 데이터들의 집합으로서, 예를 들어 C++ 언어에서 정의된 하나의 구조체이거나 게임에서 캐릭터의 움직임을 표현하기 위해 사용되는 비트맵 데이터들의 집합일 수 있다는 것은 이미 상기한 바와 같다. The resource object may be a collection of related resource data, for example, a structure defined in the C ++ language, or a collection of bitmap data used to express a character's movement in a game. Same as one.

상기 바이트 정렬(Byte alignment)은 중앙처리장치의 메인 메모리 액세스 속도를 높이기 위하여 사용되는 방법으로서, 중앙처리장치에서는 n Byte의 배수 단위로 메모리 주소를 액세스하도록 구성하고, 모든 데이터는 자신의 크기(n Byte)에 따라 그 배수의 번지에 위치하도록 정렬하여 메모리에 저장하는 것이다. 이에 따르면 각각의 데이터들은 자신의 크기에 따라 저장될 수 있는 메모리 주소의 패턴이 정해지고, 이 패턴에 따라 데이터가 정렬되면 중앙처리장치는 n Byte의 배수 단위로만 메모리를 액세스하면 되므로 속도가 크게 향상된다. The byte alignment is a method used to speed up the main memory access of the central processing unit. The central processing unit is configured to access the memory address in units of n bytes, and all data have its size (n Byte) is arranged in the address of the multiple and stored in memory. According to this, each data has a pattern of memory address that can be stored according to its size. If the data is arranged according to this pattern, the central processing unit only needs to access the memory in multiples of n bytes, which greatly improves the speed. do.

이에 반해, 데이터가 바이트 정렬되어 있지 않으면 속도가 저하되거나 시스템이 다운된다. 예를 들어, 32bit 중앙처리장치의 경우에 4 Byte 정렬을 하는데 메모리에 저장되는 데이터 중에서 4의 배수형 주소로 정렬되지 않은 것이 있다면, 인텔 x86 계열의 프로세서는 이 데이터를 읽어 들이기 위해서 두 번 메모리를 액세스해야 하므로 정렬된 데이터를 읽는 경우보다 2배 속도가 저하된다. 더욱이 ARM이나 MIPS와 같은 프로세서는 "bus error"라는 치명적인 에러를 발생시키고 시스템이 다운되기도 한다. On the other hand, if the data is not byte aligned, it will slow down or the system will crash. For example, in the case of a 32-bit central processing unit, if a 4-byte alignment occurs and any of the data stored in the memory is not aligned with a multiple address of 4, the Intel x86 family of processors will need to use the memory twice to read this data. Access is slower by 2 times than reading sorted data. Moreover, processors such as ARM and MIPS generate a fatal error called "bus error" and cause the system to crash.

본 발명은 리소스 파일을 생성하는 과정에 바이트 정렬 방식을 적용함으로써 중앙처리장치의 퍼포먼스를 크게 향상시킨다. 보다 상세하게 설명하면, 본 발명은 각각의 리소스 객체를 구성하는 모든 리소스 데이터를 각 리소스 객체별로 바이트 정렬할 뿐만 아니라, 상기 바이트 정렬된 각각의 리소스 객체들 간에도 바이트 정렬을 통해 결합시켜 최종적으로 리소스 파일을 생성한다.The present invention greatly improves the performance of the central processing unit by applying the byte sorting method to the process of generating the resource file. In more detail, the present invention not only byte-aligns all resource data constituting each resource object by each resource object, but also combines the byte-aligned resources of each of the byte-aligned resource objects through a byte-alignment to finally obtain a resource file. Create

도 4에는 본 발명에 따라 적용되는 2가지 정렬 방식, 즉 (a) 리소스 객체 내의 바이트 정렬과 (b) 리소스 객체 간의 바이트 정렬 방식의 간단한 예가 C++ 언어의 구조체를 대상으로 상세히 비교 도시되어 있다. 4 illustrates a simple example of two sorting schemes applied according to the present invention, namely (a) byte sorting within a resource object and (b) byte sorting between a resource object in detail for a structure of the C ++ language.

먼저, 도 4의 (a)에는 5개의 서로 다른 크기를 가진 변수 데이터(리소스 데이터)로 구성된 구조체(리소스 객체) A가 바이트 정렬된 실시예가 도시되어 있다. 상기 구조체 A는 다음과 같은 변수 데이터로 구성된다. First, FIG. 4A illustrates an embodiment in which a structure (resource object) A composed of variable data (resource data) having five different sizes is byte-aligned. The structure A is composed of the following variable data.

{구조체} A{Structure} A

intint a (4 a (4 bytebyte ))

charchar b (1 b (1 bytebyte ))

shortshort c (2 c (2 bytebyte ))

charchar d (1 d (1 bytebyte ))

구조체 B의 참조 포인터Reference pointer to structure B e (4 e (4 bytebyte ))

상기한 바와 같이, 바이트 정렬되는 리소스 데이터들은 자신의 크기에 따라 저장될 수 있는 메모리 주소의 패턴이 정해진다. 즉 1 byte 크기의 데이터는 어떠한 주소 번지에도 저장될 수 있고, 2 byte 크기의 데이터는 2의 배수의 주소 번지에 저장될 수 있으며, 4byte 크기의 데이터는 4의 배수의 주소 번지에 저장될 수 있다. As described above, the resource data that is byte-aligned has a pattern of a memory address that can be stored according to its size. That is, 1 byte of data can be stored at any address, 2 byte of data can be stored at an address of multiples of 2, and 4 byte of data can be stored at an address of multiples of 4. .

이에 따라 구조체 A의 변수 데이터 중 정수변수(int) a는 4 byte 크기로서 0번지부터 저장되고, 문자변수(char) b는 1 byte 크기로서 4번지에 저장된다. 그 후, 정수변수(short) c는 2 byte 크기이므로 5번지에 저장되지 못하고 2의 배수인 6번지부터 저장된다. 그 결과 5번지는 빈 공간으로 남게 되는데, 이와 같이 리소스 데이터 간의 바이트 정렬을 위하여 삽입되는 빈 공간을 패드(pad)라 하고, 이러한 처리를 패딩(padding)이라 한다. Accordingly, the integer variable a of the variable data of the structure A is stored from address 0 as 4 bytes in size, and the char variable b is stored in address 4 as 1 byte in size. After that, since the integer c is 2 bytes in size, it cannot be stored at address 5, but is stored at address 6, which is a multiple of 2. As a result, address 5 is left as an empty space. The empty space inserted for byte alignment between resource data is called a pad, and this process is called padding.

계속해서 문자변수(char) d는 1 byte 크기로서 8번지에 저장되고, 참조 포인터 변수인 e는 32bit 시스템의 경우 4 byte의 크기를 가지므로 9번지에 저장되지 못하고 4의 배수인 12번지부터 저장된다. 그 결과, 9,10,11번지는 모두 패딩 처리된다.The character variable (char) d is stored in address 8 as 1 byte size, and the reference pointer variable e is stored in address 8, which is a multiple of 4, because it is 4 byte size in 32bit system. do. As a result, addresses 9, 10, and 11 are all padded.

이러한 바이트 정렬은 상기 S10 단계를 통해 바이트 정렬된 각각의 리소스 객체들을 결합하여 하나의 리소스 파일을 생성하는 S20 단계에서도 적용될 수 있다. 도 4의 (b)에는 2개의 구조체(리소스 객체)가 바이트 정렬을 통해 결합된 실시예가 도시되어 있는 바, 구조체 A, B는 다음과 같은 변수 데이터로 구성된다. This byte alignment may be applied to the step S20 of generating a single resource file by combining each resource object byte-aligned through the step S10. 4B illustrates an embodiment in which two structures (resource objects) are combined through byte alignment, and structures A and B are composed of the following variable data.

{구조체} A{Structure} A {구조체} B{Structure} B

intint a(4 a (4 bytebyte )) charchar x(1 x (1 bytebyte ))

charchar b(1 b (1 bytebyte )) shortshort y(2 y (2 bytebyte ))

intint z(4 z (4 bytebyte ))

도 4의 (b)에서 보듯이 구조체 A의 정수변수(int) a는 0번지부터 저장되고, 문자변수(char) b는 4번지에 저장된다. 32bit 시스템에서 리소스 객체들 간에는 4byte 정렬을 하므로 구조체 B의 첫 번째 문자변수(char) x는 5번지에 저장되는 것이 아니라 4의 배수인 8번지에 저장되고 5,6,7번지는 패딩 처리된다. 그리고, 정수변수(short) y는 2 byte 크기이므로 10번지에 저장되고 9번지는 패딩 처리된다. 마지막으로 정수변수(int) z는 4byte 크기이므로 12번지부터 저장된다.As shown in (b) of FIG. 4, the integer variable a of the structure A is stored from address 0, and the character variable char b is stored at address 4. In the 32-bit system, 4 byte alignment is performed between resource objects. Therefore, the first char variable x of structure B is not stored at address 5, but is stored at address 8, which is a multiple of 4, and addresses 5, 6, and 7 are padded. In addition, since integer variable (short) y is 2 bytes in size, it is stored in address 10 and address 9 is padded. Finally, integer variable z is stored at address 12 because it is 4 bytes in size.

이상에서 설명한 바와 같이, 바이트 정렬 방식은 리소스 객체 내의 리소스 데이터를 바이트 정렬하는 경우(S10) 및 리소스 객체 간에 바이트 정렬하는 경우(S20)에 모두 적용되어 중앙처리장치의 퍼포먼스를 향상시킬 수 있다.As described above, the byte sorting method may be applied to both the case of byte sorting resource data in the resource object (S10) and the case of byte sorting between resource objects (S20), thereby improving performance of the CPU.

한편 상기 S10 단계는, 상기 각각의 리소스 객체 내에 저장된 모든 리소스 데이터들을 로딩한 다음 어플리케이션에서 실제로 필요로 하는 데이터만을 추출하여 바이트 정렬하도록 하는 것이 바람직하다. On the other hand, in step S10, it is preferable to load all the resource data stored in each of the resource objects, and then extract only the data actually needed by the application and byte alignment.

예를 들어, 게임 어플리케이션에서는 캐릭터의 연속 동작을 표현한 비트맵 데이터의 집합을 리소스 파일(바이너리 또는 텍스트 파일)로 제작하여 많이 사용한다. 이 리소스 파일은 포토샵과 같은 일러스트 프로그램을 이용하여 캐릭터의 동작 하나하나를 별도의 그림 파일(리소스 데이터)로 만든 다음 이를 결합하여 제작하기 때문에, 각각의 그림 파일에는 실제 리소스 객체로 변환하는데 필요한 각 픽셀별 색상 정보 이외에도 파일전체 사이즈, 파일 포맷, 색상수(BPP)와 같은 불필요한 헤더정보가 포함되어 있다. For example, in a game application, a set of bitmap data representing a continuous motion of a character is used as a resource file (binary or text file). This resource file uses an illustration program such as Photoshop to make each character's motion into a separate picture file (resource data), which is then combined to create each picture file. In addition to the other color information, unnecessary header information such as the total file size, the file format, and the number of colors (BPP) is included.

따라서, S10 단계에서는 각각의 그림 파일에 대한 모든 데이터를 로딩한 다음 헤더 정보는 제외하고 게임 어플리케이션에서 실제로 필요로 하는 각 픽셀별 색상 정보만을 추출하여 바이트 정렬하면 메모리 공간을 최대한 절약할 수 있다. Therefore, in the step S10, after loading all the data for each picture file, except for the header information, extract only the pixel information for each pixel actually needed in the game application and byte alignment can save the memory space to the maximum.

다음으로 상기 S20 단계는, 상기 바이트 정렬된 각각의 리소스 객체를 결합시켜 하나의 리소스 파일(Resource file)을 만든다. 도 1을 참조로 설명한 바와 같이, 최근에는 실행 코드로 된 어플리케이션 파일(4)과는 별도로 리소스 파일(5)을 생성하여 관리하는 추세이므로, 본 발명에 따른 리소스 파일 생성용 컴파일러도 상기 S10 단계에서 바이트 정렬된 복수개의 리소스 데이터를 결합시켜 하나의 리소스 파일(5)을 생성한다. Next, in step S20, the resource objects arranged in byte combination are combined to create one resource file. As described with reference to FIG. 1, in recent years, the resource file 5 is generated and managed separately from the application file 4 made of executable code. Therefore, the compiler for generating a resource file according to the present invention is also performed at step S10. One resource file 5 is created by combining the plurality of byte-aligned resource data.

또한 상기 S20 단계는, 상기 바이트 정렬된 각각의 리소스 객체들 간에도 바 이트 정렬을 통하여 결합시킴으로써 메모리의 액세스 속도를 향상시켜주는 것이 바람직하다. 리소스 객체들 간의 바이트 정렬에 대한 상세한 내용은 상기 도 4의 (b)를 참조로 상술하였으므로 생략하기로 한다.In addition, in the step S20, it is preferable to improve the access speed of the memory by combining the byte-aligned respective resource objects through byte alignment. Details of byte alignment between resource objects have been described above with reference to FIG.

또한 상기 S20 단계는, 상기 바이트 정렬된 각각의 리소스 객체를 참조되는 순서에 따라 재배열한 다음 이를 결합시키는 것이 바람직하다. 상기 도 2의 (b)에 도시된 바와 같이 종래에는 리소스 객체 A, B, C, F, I, S의 순서로 배열되어 하나의 리소스 파일을 구성하고 있다. 따라서, 상기 리소스 객체 A는 그 내부에서 리소스 객체 B, S를 참조하는데, 리소스 객체 B는 리소스 객체 A와 인접하게 저장되는 반면 리소스 객체 S는 리소스 객체 A와 상대적으로 멀리 떨어져 저장된다. In addition, in the step S20, it is preferable to rearrange each of the byte-aligned resource objects in the order of reference and then combine them. As shown in (b) of FIG. 2, conventionally, one resource file is arranged in the order of resource objects A, B, C, F, I, and S. Thus, the resource object A refers to resource objects B and S therein, where the resource object B is stored adjacent to the resource object A while the resource object S is stored relatively far from the resource object A.

이에 반해, 본 발명에 따르면 리소스 파일 생성용 컴파일러가 상기 S10 단계에서 각각의 리소스 객체별로 바이트 정렬하는 동안 리소스 객체 간의 참조 관계를 별도로 저장하고, S20 단계에서 각각의 리소스 객체를 상기 저장된 참조 순서에 따라 재배열한 다음 이를 결합시킨다. 그 결과, 도 2의 (b)와 같이 구성된 리소스 파일은 리소스 객체 A, B, S, C, F, G, I의 순서로 재배열되어 리소스 객체 S가 이를 참조하는 리소스 객체 A와 인접하게 저장된다. 이와 같이, 참조 관계에 있는 리소스 객체들이 인접하게 저장되면 캐쉬 메모리에 함께 로딩되어 힛팅(hitting)될 확률이 높아지므로 메모리 액세스 속도가 향상된다. In contrast, according to the present invention, the resource file generation compiler separately stores reference relations between resource objects during byte sorting for each resource object in step S10, and stores each resource object according to the stored reference order in step S20. Rearrange and combine them. As a result, the resource files configured as shown in FIG. 2B are rearranged in the order of resource objects A, B, S, C, F, G, and I, and are stored adjacent to the resource object A to which the resource object S refers to them. do. As such, when the resource objects in the reference relationship are stored adjacently, the probability of loading and hitting together in the cache memory increases, thereby improving memory access speed.

마지막으로 상기 S30 단계는, 상기 각각의 리소스 객체의 내부에서 참조하는 다른 리소스 객체에 대한 인덱스 정보를 상기 리소스 파일을 구성하는 첫 번째 리소스 객체의 시작번지를 기준으로 한 오프셋(offset)으로 계산하여 상기 각각의 리 소스 객체 내에 직접 저장한다.Finally, in step S30, the index information of the other resource objects referred to in the respective resource objects is calculated as an offset from the start address of the first resource object constituting the resource file. Stored directly within each resource object.

이 S30 단계는 본 발명의 가장 중요한 기술적 특징으로서, 도 2의 (b)에 도시된 종래의 리소스 파일의 포맷과 달리 인덱스 파일(8)을 별도로 생성하지 아니하고, 해당 리소스 객체에 그 내부에서 참조하는 다른 리소스 객체의 시작번지를 계산할 수 있는 인덱스 정보를 직접 저장함으로써, 중앙처리장치가 일일이 인덱스 파일을 참조하지 아니하고도 하나의 리소스 객체에서 다른 리소스 객체를 직접 액세스할 수 있도록 해준다.This step S30 is the most important technical feature of the present invention. Unlike the conventional resource file format shown in FIG. 2B, the index file 8 is not generated separately, and the resource object is referred to therein. By directly storing index information to calculate the start address of other resource objects, the central processing unit can directly access other resource objects from one resource object without referring to the index file.

도 5에는 이와 같이 구성된 본 발명에 따른 리소스 파일의 포맷이 도시되어 있다. 도 5의 (a)는 상기 도 2의 (a)와 동일한 것으로, 컴퓨터의 메인 메모리(6)에 리소스 객체 A, B, C, F, G, I, S를 위한 공간이 할당되고, 리소스 객체 A는 그 내부에서 리소스 객체 B, S를 순차적으로 참조하며, 리소스 객체 G는 리소스 객체 F, I를 순차적으로 참조하고, 리소스 객체 C는 리소스 객체 F를 참조하도록 구성된 일 예가 도시되어 있다.5 shows the format of the resource file according to the present invention configured as described above. 5 (a) is the same as FIG. 2 (a), the space for resource objects A, B, C, F, G, I, S is allocated to the main memory 6 of the computer, and the resource object A sequentially refers to resource objects B and S therein, resource object G sequentially refers to resource objects F and I, and resource object C is illustrated as an example configured to refer to resource object F. FIG.

도 5의 (b)는 종래 리소스 파일의 포맷을 도시한 상기 도 2의 (b)와 대응되는 것으로서 본 발명에 따라 생성된 새로운 형태의 리소스 파일(10)의 포맷이 도시되어 있다. 참고로, 이 리소스 파일(10)은 본 발명에 따른 상기 S10, S20 단계를 통하여 각각의 리소스 객체들이 바이트 정렬되고 각각의 참조 순서에 따라 배열되어 있다. FIG. 5 (b) corresponds to FIG. 2 (b) illustrating the format of a conventional resource file, and shows a format of a new type resource file 10 generated according to the present invention. For reference, this resource file 10 is arranged in accordance with the respective reference order by the respective resource objects are byte-aligned through the steps S10 and S20 according to the present invention.

도 5의 (b)에 도시된 본 발명에 따른 리소스 파일(10)의 포맷과 도 2의 (b)에 도시된 종래의 리소스 파일의 포맷의 가장 큰 차이점은 상기 S30 단계를 통하여 각각의 리소스 객체 내에 참조하는 리소스 객체의 인덱스 정보가 직접 저장되어 별도의 인덱스 파일이 없다는 것이다.The biggest difference between the format of the resource file 10 according to the present invention shown in FIG. 5 (b) and the format of the conventional resource file shown in FIG. 2 (b) is obtained through the step S30. The index information of the resource object referenced in it is directly saved, so there is no separate index file.

예를 들어, 리소스 객체 A가 저장되는 공간에는 리소스 객체 A의 실제 정보와 함께 리소스 객체 A의 내부에서 참조하는 리소스 객체 B와 S의 인덱스 정보가 저장된다. 이 인덱스 정보는 종래와 같이 인덱스 파일을 참조하는데 사용되는 단순한 Key 정보가 아니라, 중앙처리장치가 인덱스 정보를 이용하여 리소스 객체 B와 S가 저장된 메인 메모리로 직접 접근할 수 있도록 해주는 것이다. For example, in the space where the resource object A is stored, index information of resource objects B and S that are referred to from the inside of the resource object A is stored together with the actual information of the resource object A. The index information is not simply key information used to refer to the index file as in the related art, but allows the central processing unit to directly access the main memory in which the resource objects B and S are stored using the index information.

이를 위해 상기 인덱스 정보는 전체 리소스 파일을 구성하는 첫 번째 리소스 객체의 시작번지를 기준으로 한 오프셋(offset)으로 계산된다. 상기 첫 번째 리소스 객체의 시작번지는 실제로 상기 리소스 파일이 메인 메모리에 로딩되기 전까지는 정해지지 않기 때문에, 본 발명에 따른 리소스 파일 생성용 컴파일러에 의해 컴파일될 때에는 임의로 설정되는 가상의 메모리 주소로 지정된다. 이 가상의 메모리 주소를 기준으로 각각의 리소스 객체의 크기에 따른 상대적 주소 거리인 오프셋이 실제 인덱스 정보로 저장된다.  To this end, the index information is calculated as an offset based on the start address of the first resource object constituting the entire resource file. Since the start address of the first resource object is not determined until the resource file is actually loaded into the main memory, it is designated as a virtual memory address that is arbitrarily set when compiled by the resource file generation compiler according to the present invention. Based on this virtual memory address, an offset, which is a relative address distance according to the size of each resource object, is stored as actual index information.

예를 들어, 상기 첫 번째 리소스 객체 A의 시작 번지가 가상의 메모리 주소인 [00000]으로 설정되고, 상기 리소스 객체 A의 크기가 4 Kbyte, 리소스 객체 B의 크기가 16 Kbyte라면, 상기 리소스 객체 A에 저장되는 리소스 객체 B의 인덱스 정보는 [01000]이 되고, 리소스 객체 S의 인덱스 정보는 [06000]이 된다. 따라서, 리소스 파일(10)의 첫 번째 리소스 객체 A에는 그 실제 정보와 함께 리소스 객체 B의 인덱스 정보 [01000]와 리소스 객체 S의 인덱스 정보 [06000]이 함께 저장된다.For example, if the start address of the first resource object A is set to a virtual memory address, and the size of the resource object A is 4 Kbytes, the size of the resource object B is 16 Kbytes, the resource object A Index information of the resource object B stored in the resource object S becomes [01000], and index information of the resource object S becomes [06000]. Therefore, the index information [01000] of the resource object B and the index information [06000] of the resource object S are stored together with the actual information in the first resource object A of the resource file 10.

이와 같이 생성된 본 발명에 따른 리소스 파일(10)은 중앙처리장치에 의해 메인 메모리로 로딩될 때 항상 리소스 객체 A, B, S, C, F, G, I가 결합된 하나의 파일로 할당된다. 따라서, 중앙처리장치는 메모리 관리자로부터 상기 리소스 파일(10)을 저장하기 위해 할당된 메모리 공간의 첫 번째 시작번지를 전송받아 임시로 저장한 다음 리소스 파일(10) 내에 저장된 모든 인덱스 정보를 실제 메모리 주소로 갱신한 다음 메인 메모리에 저장한다. The resource file 10 according to the present invention generated as described above is always assigned to one file in which resource objects A, B, S, C, F, G, and I are combined when loaded into the main memory by the central processing unit. . Therefore, the CPU receives the first starting address of the memory space allocated to store the resource file 10 from the memory manager and temporarily stores the first starting address of the allocated memory space, and then stores all index information stored in the resource file 10 in the actual memory address. Update it and save it to main memory.

예를 들어, 리소스 파일(10)을 저장하기 위해 할당된 메모리 공간의 첫 번째 시작번지가 [000FF]라고 할 때, 중앙처리장치는 상기 리소스 객체 A 내에 저장된 리소스 객체 B의 인덱스 정보를 [000FF](리소스 파일의 실제 시작번지) + [01000](리소스 객체 B의 오프셋) = [010FF]로 갱신하고, 리소스 객체 S의 인덱스 정보는 [000FF](리소스 파일의 실제 시작번지) + [06000](리소스 객체 S의 오프셋) = [060FF]로 갱신한다. 이러한 방법으로 리소스 파일(10) 내부에 있는 모든 인덱스 정보를 실제 할당되는 메모리의 주소 번지로 갱신한다. For example, when the first starting address of the memory space allocated for storing the resource file 10 is [000FF], the CPU receives index information of the resource object B stored in the resource object A. (Real start address of resource file) + [01000] (offset of resource object B) = [010FF], and index information of resource object S is [000FF] (actual start address of resource file) + [06000] ( Offset of resource object S) = [060FF]. In this way, all index information in the resource file 10 is updated to the address of the memory that is actually allocated.

그 후, 중앙처리장치가 해당 어플리케이션을 실행하면서 리소스 객체 A를 참조하고자 하는 때에는, 먼저 리소스 파일(10)의 시작번지를 참조로 리소스 객체 A를 액세스한다. 그리고, 도 5의 (b)에 도시된 바와 같이 리소스 객체 A의 내부에서 참조하는 리소스 객체 B는 그 인덱스 정보 [010FF]를 이용하여 직접 액세스한다(과정 ①). 동일한 방법으로 리소스 객체 A의 내부에서 참조하는 리소스 객체 S는 그 인덱스 정보 [060FF]를 이용하여 직접 액세스한다(과정 ②). 이와 같이, 본 발명에 따라 생성된 리소스 파일(10)을 이용하는 경우 중앙처리장치는 리소스 객체 A, B, F를 차례로 참조하는데 3번의 메모리 액세스만으로 가능하게 되며, 이는 도 2의 (b)에 도시된 종래의 리소스 파일 포맷을 사용하는 경우 5번의 메모리 참조를 해야하는 경우와 비교할 때 40%의 속도 향상 효과를 발휘한다.Thereafter, when the CPU wants to refer to the resource object A while executing the corresponding application, the resource object A is first accessed by referring to the start address of the resource file 10. As shown in FIG. 5B, the resource object B referred to from the inside of the resource object A is directly accessed using the index information [010FF] (process ①). In the same manner, the resource object S referenced in the resource object A is directly accessed using the index information [060FF] (process ②). As such, when using the resource file 10 generated in accordance with the present invention, the central processing unit refers to the resource objects A, B, and F in turn, and only three memory accesses are possible, which is illustrated in FIG. When using the conventional resource file format, a speed increase of 40% is achieved compared with the case where five memory references are required.

본 발명에 따라 생성된 리소스 파일을 사용하는 경우 기대되는 효과를 메인 메모리에서 메모리 컴팩션(Memory compaction)이 발생하는 경우와 발생하지 않는 경우로 나누어 더욱 구체적으로 설명한다. 참고로 메모리 컴팩션이란 함은 메모리 단편화(Memory fragmentation)로 인해 발생되는 메모리 할당의 비효율성을 감소시키기 위해 메모리의 상황에 따라 할당된 메모리를 재배치하여 할당가능한 공간을 묶어 효율적으로 메모리를 사용할 수 있도록 해주는 기법이다. 이러한 메모리 컴팩션이 일어나면 이전에 할당되어 있던 데이터들도 그 메모리 주소가 변경된다. When using a resource file generated according to the present invention will be described in more detail by dividing the expected effect into the case where the memory compact (Memory compaction) occurs in the main memory or not. For reference, memory compaction means that memory allocation can be efficiently used by relocating the allocated memory according to the memory situation in order to reduce the inefficiency of memory allocation caused by memory fragmentation. It is a technique. When this memory compaction occurs, previously allocated data also changes its memory address.

먼저, 메모리 컴팩션이 발생하지 않는 때에는 도 2의 (b)와 같이 인덱스 파일(8)을 사용하는 경우에도 리소스 파일(7)을 메인 메모리로 로딩하는 과정에서 상기 인덱스 파일(8)에 저장되어 있는 각 리소스 객체의 위치, 크기 또는 종류 등의 정보를 분석하여 Key 정보가 아니라 리소스 객체를 직접 참조할 수 있는 정보를 저장한다. 따라서, 종래의 리소스 파일(7)도 한번 저장된 후에는 도 5의 (b)에 도시된 본 발명의 리소스 파일(10)과 유사한 속도로 실행될 수 있다. First, when memory compaction does not occur, even when the index file 8 is used as shown in FIG. 2B, the resource file 7 is stored in the index file 8 in the process of loading the resource file 7 into the main memory. It analyzes the information such as the location, size or type of each resource object, and stores the information that can refer directly to the resource object instead of the key information. Therefore, once the conventional resource file 7 is also stored once, it can be executed at a similar speed as the resource file 10 of the present invention shown in FIG.

그러나, 리소스 파일(7)을 메인 메모리에 최초로 로딩할 때 메인 메모리에 인덱스 파일(8)을 별도로 할당하고 이 인덱스 파일(8)을 일일이 참조하여 각 리소스 객체에 대한 정보를 분석해야 하므로 시간이 오래 소요된다. However, when the resource file 7 is first loaded into the main memory, the index file 8 must be separately allocated to the main memory and the index file 8 must be referred to to analyze the information on each resource object. It takes

반면, 본 발명의 경우에는 중앙처리장치가 본 발명에 따른 리소스 파일(10) 이 할당되는 메모리 공간의 시작 번지만을 레지스터 등에 임시로 저장한 다음 해당 리소스 파일(10)을 로딩하여 그 내부에 있는 모든 인덱스 정보를 한꺼번에 갱신하면 되고, 이 과정에서 메인 메모리를 액세스할 필요가 없으므로 매우 신속하게 처리된다. 그 결과, 해당 리소스 파일(10)을 메인 메모리로 로딩하는 속도가 현저히 향상된다.On the other hand, in the case of the present invention, the central processing unit temporarily stores only the start address of the memory space to which the resource file 10 according to the present invention is allocated, and then loads the corresponding resource file 10 to store all of the resources therein. The index information can be updated all at once, and this process is very fast because there is no need to access the main memory. As a result, the speed of loading the resource file 10 into the main memory is significantly improved.

한편, 메모리 컴팩션이 발생하는 때에는 미리 저장된 리소스 파일의 메모리 주소가 동적으로 변경되기 때문에, 종래의 경우에는 도 2의 (b)와 같이 인덱스 파일(8)과 리소스 파일(7)을 동시에 메인 메모리에 저장하고, 메모리 관리자가 제공하는 핸들을 별도로 저장해 두었다가 해당 리소스 객체를 액세스하는 시점에서 메모리 관리자에게 핸들을 전달하여 핸들이 가리키는 리소스 객체의 인덱스 정보를 얻어 액세스하게 된다. On the other hand, when memory compaction occurs, since the memory address of the prestored resource file is dynamically changed, in the conventional case, the index file 8 and the resource file 7 are simultaneously main memory as shown in FIG. In this case, the handle provided by the memory manager is stored separately, and when the resource object is accessed, the handle is passed to the memory manager to obtain the index information of the resource object pointed to by the handle.

반면, 본 발명의 경우에는 도 5의 (b)에 도시된 바와 같이 리소스 객체 A, B, S, C, F, G, I가 순서대로 결합된 리소스 파일(10)이 항상 하나의 단위로 메모리에 할당되므로, 메모리 컴팩션이 일어나더라도 전체가 재배치될 뿐 리소스 객체들 간의 배열순서는 변경되지 아니한다. 따라서, 메모리 컴팩션이 일어나더라도 리소스 파일(10)의 시작번지만이 변경되므로, 중앙처리장치는 리소스 객체에 접근하는 시점에 메모리 관리자로부터 메모리 컴팩션에 의해 변경된 리소스 파일의 시작번지를 얻어 리소스 객체들의 인덱스 정보를 재갱신시켜주기만 하면 된다. 그러므로, 매번 인덱스 파일(8)을 참조하여 핸들을 실제 주소로 변환해주어야 하는 종래보다 실행 속도가 현저히 향상된다. On the other hand, in the case of the present invention, as shown in (b) of FIG. 5, the resource file 10 in which the resource objects A, B, S, C, F, G, and I are sequentially combined is always stored as one unit of memory. Since the memory compaction occurs, the entire memory is rearranged, but the order of the resource objects is not changed. Therefore, even when memory compaction occurs, only the start address of the resource file 10 is changed, so that the CPU obtains the start address of the resource file changed by the memory compaction from the memory manager when the resource object is accessed. You just need to update their index information. Therefore, the execution speed is remarkably improved compared with the conventional method in which the handle must be converted into an actual address with reference to the index file 8 every time.

이상에서 설명한 바와 같이, 본 발명에 따르면 중앙처리장치가 어플리케이션을 실행하면서 리소스 파일을 참조하는 때에 메모리 내에서 리소스 객체의 배치를 최적화하여 리소스 객체의 로딩 속도 또는 실행 속도를 크게 향상시킨다. 부수적으로, 본 발명은 연관성 있는 리소스 객체들을 하나의 파일로 할당하고 인덱스 파일과 같은 별도의 자료를 위한 메모리 할당이 발생하지 않기 때문에 메모리 단편화를 방지하는 효과도 얻을 수 있다. As described above, according to the present invention, when the central processing unit refers to a resource file while executing an application, the placement of the resource object in the memory is optimized to greatly increase the loading speed or execution speed of the resource object. Incidentally, the present invention can also obtain an effect of preventing memory fragmentation because the associated resource objects are allocated to one file and memory allocation for separate data such as an index file does not occur.

이러한 본 발명은 휴대폰과 같이 메모리의 용량이 한정되는 시스템에서 게임과 같이 리소스를 많이 사용하는 어플리케이션을 구현할 때 가장 효과적으로 이용될 수 있다. 그러나, 본 발명의 기술적 사상은 이에 한정되지 아니하며 컴퓨터 시스템에서 구현되는 모든 어플리케이션에서 필요로 하는 다양한 종류의 리소스를 관리하는데 이용될 수 있음은 물론이다. The present invention can be most effectively used when implementing a resource-intensive application such as a game in a system where the capacity of the memory such as a mobile phone is limited. However, the technical idea of the present invention is not limited thereto and may be used to manage various types of resources required by all applications implemented in a computer system.

도 1은 일반적인 어플리케이션의 구성을 나타낸 도면.1 is a view showing the configuration of a general application.

도 2는 종래의 리소스 파일의 포맷을 나타낸 도면.2 is a diagram illustrating a format of a conventional resource file.

도 3은 본 발명에 따른 리소스 파일 생성방법을 도시한 순서도.3 is a flowchart illustrating a method of generating a resource file according to the present invention.

도 4는 본 발명에 따른 바이트 정렬을 나타낸 도면.4 illustrates byte alignment in accordance with the present invention.

도 5는 본 발명에 따른 리소스 파일의 포맷을 나타낸 도면.5 illustrates the format of a resource file according to the present invention.

※도면의 주요 부분에 대한 부호의 설명※※ Explanation of code for main part of drawing ※

1: 어플리케이션 파일 2: 실행 코드1: application file 2: executable code

3: 리소스 4: 어플리케이션 파일3: resource 4: application files

5: 리소스 파일 6: 메인 메모리5: resource file 6: main memory

7: 리소스 파일 8: 인덱스 파일7: Resource file 8: Index file

10: 리소스 파일10: Resource file

Claims (5)

(a) 각각의 리소스 객체(Resource object) 내에 저장된 리소스 데이터들을 순차적으로 로딩하여 리소스 객체별로 바이트 정렬(Byte alignment)하는 단계;(a) sequentially loading resource data stored in each resource object and byte alignment for each resource object; (b) 상기 바이트 정렬된 각각의 리소스 객체들 간에도 바이트 정렬을 통하여 결합시킴으로써 하나의 리소스 파일(Resource file)을 만드는 단계;(b) creating a single resource file by combining through byte alignment even between each of the byte aligned resource objects; (c) 상기 각각의 리소스 객체 내부에서 참조하는 다른 리소스 객체에 대한 인덱스 정보를 상기 리소스 파일을 구성하는 첫 번째 리소스 객체의 시작번지를 기준으로 한 오프셋(offset)으로 계산하여 상기 각각의 리소스 객체 내에 직접 저장하는 단계;를 포함하는 것을 특징으로 하는 메모리 최적화를 위한 리소스 파일 생성방법. (c) calculate index information of another resource object referred to inside each resource object as an offset based on a start address of a first resource object constituting the resource file, and then calculate the index information in each resource object. Resource file generation method for memory optimization comprising a; directly storing. 청구항 1에 있어서, 상기 (a) 단계는, 상기 각각의 리소스 객체 내에 저장된 모든 리소스 데이터들을 로딩한 다음 어플리케이션에서 실제로 필요로 하는 데이터만을 추출하여 바이트 정렬하는 것을 특징으로 하는 메모리 최적화를 위한 리소스 파일 생성방법.The method of claim 1, wherein the step (a) loads all of the resource data stored in each resource object, and then extracts and byte-aligns only the data actually needed by the application to create a resource file for memory optimization. Way. 삭제delete 청구항 1에 있어서, 상기 (b) 단계는, 상기 바이트 정렬된 각각의 리소스 객체를 참조되는 순서에 따라 재배열한 다음 이를 결합시키는 것을 특징으로 하는 메모리 최적화를 위한 리소스 파일 생성방법. The method of claim 1, wherein the step (b) rearranges each of the byte-aligned resource objects in the order of reference and then combines them. 청구항 1에 있어서, 상기 (c) 단계는, 상기 첫 번째 리소스 객체의 시작번지가 가상의 메모리 주소인 것을 특징으로 하는 메모리 최적화를 위한 리소스 파일 생성방법.The method of claim 1, wherein in step (c), the start address of the first resource object is a virtual memory address.
KR1020070125908A 2007-12-06 2007-12-06 Method for creating resource file for optimizing memory KR100913111B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020070125908A KR100913111B1 (en) 2007-12-06 2007-12-06 Method for creating resource file for optimizing memory

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020070125908A KR100913111B1 (en) 2007-12-06 2007-12-06 Method for creating resource file for optimizing memory

Publications (2)

Publication Number Publication Date
KR20090059195A KR20090059195A (en) 2009-06-11
KR100913111B1 true KR100913111B1 (en) 2009-08-19

Family

ID=40989345

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020070125908A KR100913111B1 (en) 2007-12-06 2007-12-06 Method for creating resource file for optimizing memory

Country Status (1)

Country Link
KR (1) KR100913111B1 (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103699413B (en) * 2013-12-24 2017-05-03 北京世界星辉科技有限责任公司 Method and system for optimizing game operating environment, client and server

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040080735A (en) * 2003-03-13 2004-09-20 삼성전자주식회사 Method for managing multimedia contents made with SMIL and SMIL file system thereof
KR100746035B1 (en) * 2006-03-07 2007-08-06 삼성전자주식회사 Apparatus and method for providing management using linear file system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040080735A (en) * 2003-03-13 2004-09-20 삼성전자주식회사 Method for managing multimedia contents made with SMIL and SMIL file system thereof
KR100746035B1 (en) * 2006-03-07 2007-08-06 삼성전자주식회사 Apparatus and method for providing management using linear file system

Also Published As

Publication number Publication date
KR20090059195A (en) 2009-06-11

Similar Documents

Publication Publication Date Title
Koshy et al. VMSTAR: synthesizing scalable runtime environments for sensor networks
JP5733860B2 (en) Efficient parallel computation of dependency problems
US7805710B2 (en) Shared code caching for program code conversion
JP3808755B2 (en) Virtual machine with JIT compiler
Debray et al. Profile-guided code compression
US20090322769A1 (en) Bulk-synchronous graphics processing unit programming
Chen et al. Heap compression for memory-constrained Java environments
JP2011527788A5 (en)
Martín et al. Algorithmic strategies for optimizing the parallel reduction primitive in CUDA
US7213237B2 (en) Intermediate code preprocessing apparatus, intermediate code execution apparatus, intermediate code execution system, and computer program product for preprocessing or executing intermediate code
US20130054546A1 (en) Hardware-based array compression
Aslam et al. Optimized java binary and virtual machine for tiny motes
Volk et al. GPU-Based Speculative Query Processing for Database Operations.
US20030086620A1 (en) System and method for split-stream dictionary program compression and just-in-time translation
Pellegrini Distillating knowledge about Scotch
Greiner et al. A provably time-efficient parallel implementation of full speculation
CN111344667B (en) System and method for compiling and executing code within virtual memory sub-pages of one or more virtual memory pages
KR100913111B1 (en) Method for creating resource file for optimizing memory
US6571387B1 (en) Method and computer program product for global minimization of sign-extension and zero-extension operations
JP2005507103A (en) Framework to realize Java heap
Li et al. GRapid: A compilation and runtime framework for rapid prototyping of graph applications on many-core processors
Sagonas et al. Experimental evaluation and improvements to linear scan register allocation
JP3896238B2 (en) Computer system and program runtime representation method
CN115495226A (en) Memory management method, device, equipment and computer readable storage medium
KR101088515B1 (en) Computer readable recording medium having install-time compiler program for embedded system

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E90F Notification of reason for final refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20120531

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20130709

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20140813

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20160801

Year of fee payment: 8

LAPS Lapse due to unpaid annual fee