View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0024824 | Community | OCCT:WOK | public | 2014-04-11 23:39 | 2015-08-19 12:37 |
| Reporter | Roman Lygin | Assigned To | bugmaster | ||
| Priority | low | Severity | feature | ||
| Status | closed | Resolution | won't fix | ||
| OS | Linux | ||||
| Product Version | 6.7.0 | ||||
| Summary | 0024824: Makefile - the list of include directories in the command line should be reordered for better performance | ||||
| Description | Currently generated Makefiles insert paths to the include directories of 3rd party tools ahead of the OCC's inc. This undermines performance, as the inc is the most likely location of the include files, so visiting 3rd-party directories is a waste of time. Moreover, if they are located on a host and are shared with a guest (when building in a virtual machine) then this waste is amplified. More optimal order would be: 1. visit OCC's inc, 2. individual drv's and src's 3. 3rd parties. Below is an example of a current command line from 6.7.0: libtool: compile: g++ -m64 -DHAVE_CONFIG_H -I. -I../../../.. -I/devel/dev/DevTools/gl2ps/1.3.5-lin64-gcc4/include -DHAVE_GL2PS -I/devel/dev/DevTools/FreeImage/3.15.0-lin64-gcc4/include -DHAVE_FREEIMAGE -I/devel/dev/DevTools/tbb/4.1.3/include -DHAVE_TBB -I../../../../inc -I../../../../drv/HLRTopoBRep -I../../../../src/HLRTopoBRep -I../../../../drv/HLRBRep -I../../../../src/HLRBRep -I../../../../drv/HLRAlgo -I../../../../src/HLRAlgo -I../../../../drv/HLRAppli -I../../../../src/HLRAppli -I../../../../drv/Intrv -I../../../../src/Intrv -I../../../../drv/TopBas -I../../../../src/TopBas -I../../../../drv/TopCnx -I../../../../src/TopCnx -I../../../../drv/Contap -I../../../../src/Contap -DOCCT_MMGT_OPT_DEFAULT=2 -D_OCC64 -DDEB -D_DEBUG -DCSFDB -DOCC_CONVERT_SIGNALS -DLIN -DLININTEL -D_GNU_SOURCE=1 -mmmx -msse -msse2 -mfpmath=sse -Wall -g -MT HLRTopoBRep_DataMapIteratorOfDataMapOfShapeFaceData_0.lo -MD -MP -MF .deps/HLRTopoBRep_DataMapIteratorOfDataMapOfShapeFaceData_0.Tpo -c ../../../../drv/HLRTopoBRep/HLRTopoBRep_DataMapIteratorOfDataMapOfShapeFaceData_0.cxx -fPIC -DPIC -o .libs/HLRTopoBRep_DataMapIteratorOfDataMapOfShapeFaceData_0.o | ||||
| Additional information and documentation updates | (Not really familiar with internals of WOK, so cannot offer a fix. Hope it should be quite trivial to make). | ||||
| Tags | No tags attached. | ||||
| Test case number | |||||
|
|
Dear Roman, >> This undermines performance, as the inc is the most likely >> location of the include files, so visiting 3rd-party directories >> is a waste of time. could you please provide actual numbers achieved in your network / locally? |
|
|
Kirill, I do not have data at hand and can hardly collect it with reasonable efforts. This would require me to understand how the Makefiles are generated by WOK, introduce the fix, regenerate the Makefile in some sandboxed version (not to affect production environment), etc. I hope we can agree that access to a shared drive (within virtual environment) or a network drive has certain costs and it does not make sense to unnecessarily pay them when searching for a header file. An analogy from code development would be to place if/else or case in switch in the order of most probable match. Hope this helps. |
|
|
Dear Roman, >> I do not have data at hand and can hardly collect it with reasonable efforts. So why do you suppose change worth efforts? If your environment does not provide any local storage to perform trivial testing, why you care about theoretical building environments with combination of network + local storage at all? We have observed some performance loss on Windows stations some time ago, but Linux networking is somewhat more efficient in general. |
|
|
Kirill, I am not sure I am following your comments. In my environment, I use a virtual Linux guest running inside a Windows host. The 3rd party libraries are on the Windows host and are shared via "Shared folder". Access via Shared folder obviously has performance penalties. The request is obvious - to avoid the need to pay those penalties as in 99+% cases the required OCC header will be found in "../../../inc" which is 4th in the list (after gl2ps, FreeImage, tbb). In the case of opencl, "inc" can probably be the 5th. We can argue about the size of the performance loss/gain but it is real and not "theoretical" anyway. It only depends on how expensive that access to 3rd party directories can be - from negligible if everything is near to highly expensive, if they reside behind Samba on some remote server. To address your question to quantify that loss/gain, I would need to find a way to generate Makefiles where the order would be as desired. As I mentioned, I am not familiar with the WOK's component in charge of generation of the Makefile. It would take me quite some time to locate that, but it will likely be very straightforward for the component owner. I don't see a strong point in debating here. Anyway, thanks for your paying attention to this enhancement request. Roman |
|
|
>> To address your question to quantify that loss/gain, >> I would need to find a way to generate Makefiles where the order would be as desired. You can obtain theoretical speed up by copying 3rd-parties to local storage. This will not answer the actual state when 3rd-parties will be still at remote path but in different inclusion order, but you'll see is your network really affect performance. |
|
|
Kirill, Some experimental measurements revealed that the benefit of eliminating unnecessary 3rd party directories is about 10% of elapsed time. As expected, the major improvement (2x-3x) came from putting sources from the host into the guest machine. Please make a decision whether single digit percentage improvement is worth your investments. It may still make sense but I agree with your triaging this request to a low priority. |
|
|
Roman, the fact is that we are working on Windows mostly, and when on Linux, we (developers) use CMake to generate makefiles. Automake scripts generated by WOK are still in use in test process, but they will get out of operation soon, perhaps even before WOK is eliminated, or together with WOK. |
|
|
Dear bugmaster, please close the issue - CMake should be used instead. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-04-11 23:39 | Roman Lygin | New Issue | |
| 2014-04-11 23:39 | Roman Lygin | Assigned To | => kgv |
| 2014-04-12 08:52 | kgv | Note Added: 0028805 | |
| 2014-04-12 08:52 | kgv | Assigned To | kgv => Roman Lygin |
| 2014-04-12 08:52 | kgv | Severity | minor => feature |
| 2014-04-12 08:52 | kgv | Status | new => feedback |
| 2014-04-12 08:52 | kgv | Summary | The list of include directories in the command line should be reordered for better performance => Makefile - the list of include directories in the command line should be reordered for better performance |
| 2014-04-12 08:52 | kgv | Description Updated | |
| 2014-04-12 10:43 | Roman Lygin | Note Added: 0028806 | |
| 2014-04-12 10:43 | Roman Lygin | Assigned To | Roman Lygin => kgv |
| 2014-04-12 10:43 | Roman Lygin | Status | feedback => assigned |
| 2014-04-12 13:52 | kgv | Note Added: 0028808 | |
| 2014-04-12 13:52 | kgv | Assigned To | kgv => Roman Lygin |
| 2014-04-12 13:52 | kgv | Status | assigned => feedback |
| 2014-04-12 23:43 | Roman Lygin | Note Added: 0028809 | |
| 2014-04-13 09:32 | kgv | Note Added: 0028810 | |
| 2014-04-13 09:32 | kgv | Priority | normal => low |
| 2014-05-13 15:25 | Roman Lygin | Note Added: 0029296 | |
| 2014-05-13 15:25 | Roman Lygin | Assigned To | Roman Lygin => kgv |
| 2014-05-13 15:25 | Roman Lygin | Status | feedback => assigned |
| 2014-05-13 15:33 |
|
Note Added: 0029297 | |
| 2014-09-12 14:20 |
|
Target Version | => 7.0.0 |
| 2015-07-27 10:32 | kgv | Note Added: 0043441 | |
| 2015-07-27 10:32 | kgv | Assigned To | kgv => bugmaster |
| 2015-07-27 10:32 | kgv | Status | assigned => feedback |
| 2015-07-27 10:32 | kgv | Resolution | open => won't fix |
| 2015-07-30 11:42 | bugmaster | Status | feedback => closed |
| 2015-08-19 12:37 |
|
Target Version | 7.0.0 => |